No es una herramienta específica, sino una técnica de depuración para rastrear qué código es responsable de las conexiones abiertas u otros recursos.
Supongo que está utilizando un método consistente en el lado java para obtener una conexión db (agrupado o no importa).
La idea es crear una clase de envoltura muy liviana alrededor de la fábrica/piscina de conexión o lo que sea.El contenedor implementará cualquier interfaz jdbc que tenga sentido para que pueda intercambiarla por su objeto de conexión normal, pero la mayoría de los métodos simplemente invocarán/devolverán la conexión subyacente.
Si está utilizando algún tipo de marco IoC (por ejemplo, primavera), debería poder cambiar fácilmente la clase de conexión/fábrica en un nivel de configuración. Ahora todo su código java usará su nueva envoltura de conexión db.
Si está utilizando un grupo, entonces llamar al connection.close() generalmente solo devuelve el objeto al grupo en lugar de destruir la conexión. Por lo tanto, esta técnica funciona para la fuga de conexión normal o simplemente "no se devuelve a la fuga del grupo (grupo agotado)".
Ahora solo tenemos que registrar los bits interesantes y establecer una trampa para las conexiones filtradas.
Seguimiento de la pila para identificar creador
En el constructor o el método de fábrica para su envoltorio conexión de crear un nuevo Throwable objeto y almacenarlo como una variable local dentro de su envoltorio para más adelante. Usamos un Throwable porque es más rápido/más barato que usando Thread.currentThread().getStackTrace().
Conjunto de la "trampa"
implementar el método finally en su clase contenedora. Este es un método de limpieza llamado por el GC cuando el objeto se destruye porque ya no se usa.
El método finally debería marcar "¿estoy cerrado?". Si ya está cerrado, todo está bien ... sin embargo, si la conexión está siendo GCed y no se ha cerrado ... entonces esta es una conexión "filtrada".
Ahora vuelve a entrar en juego el Throwable. Podemos tomar el Throwable y generar un bonito mensaje de registro que diga algo así como: "Soy una conexión filtrada y aquí hay un seguimiento de pila que implica a mi creador".
Ampliando la idea
Este método puede ser adaptado para una variedad de situaciones. Por supuesto, puede mantener otros tipos de datos en su envoltorio para solucionar su problema específico. Por ejemplo, tiempo de creación. Luego puedes buscar conexiones duraderas e implicar nuevamente al creador. O puede sondear las conexiones existentes y analizar los seguimientos de la pila Throwable para obtener datos sobre qué código está usando la cantidad de conexiones a lo largo del tiempo.
Probablemente haya una herramienta lista para usar que también puede hacer este tipo de cosas, pero la cantidad de código requerido para aplicar esta técnica es muy mínima en la mayoría de los casos (suponiendo que tiene una manera fácil de intercambiar fábrica de conexión db sin búsqueda-reemplazando toda su base de código).
Si bien P6Spy es una buena herramienta, no veo cómo ayuda con la búsqueda de problemas de fugas en las conexiones. –