Не конкретный инструмент, а скорее методика отладки для отслеживания того, какой код отвечает за открытые соединения или другие ресурсы.
Я предполагаю, что вы используете согласованный метод на стороне Java для получения соединения БД (объединено или нет, не имеет значения).
Идея состоит в том, чтобы создать очень легкий класс-оболочку для вашей фабрики соединений / пула или чего бы то ни было. Оболочка будет реализовывать любой интерфейс jdbc, который имеет смысл, так что вы можете поменять его для обычного объекта соединения, но большинство методов просто прозрачно вызывают / возвращают базовое соединение.
Если вы используете какой-то IoC-фреймворк (например, Spring), вы сможете легко поменять класс соединения / фабрики на уровне конфигурации. Теперь весь ваш java-код будет использовать вашу новую оболочку соединения с БД.
Если вы используете пул, то вызов connection.close() обычно просто возвращает объект в пул, а не разрушает соединение. Таким образом, этот метод работает для обычной утечки соединения или просто утечки "не возвращен в пул (пул исчерпан)".
Теперь нам просто нужно зарегистрировать интересные биты и установить ловушку для утечек соединений.
Трассировка стека для идентификации создателя
В методе конструктора или фабрики для вашей оболочки соединений создайте новый объект Throwable и сохраните его как локальную переменную в вашей оболочке для дальнейшего использования. Мы используем Throwable, потому что это быстрее / дешевле, чем Thread.currentThread().getStackTrace().
Установить «ловушку»
Реализуйте метод finalize в своем классе-обертке. Это метод очистки, вызываемый GC, когда объект уничтожается, потому что он больше не используется.
Метод finalize должен проверять "я закрыт?" Если уже закрыто, то все в порядке ... однако, если соединение GCed и оно не было закрыто ... тогда это соединение с утечкой.
Теперь Throwable возвращается в игру. Мы можем взять Throwable и вывести красивое сообщение в журнале, говорящее что-то вроде: «У меня утечка соединения, и вот трассировка стека, затрагивающая моего создателя».
Расширение идеи
Этот метод может быть адаптирован для различных ситуаций. Конечно, вы можете хранить другие типы данных в своей оболочке для устранения проблем, с которыми вы столкнулись. Например время создания. Затем вы можете опросить долгоживущие связи и снова привлечь создателя. Или вы можете опросить существующие соединения и проанализировать трассировки стека Throwable, чтобы получить данные о том, какой код использует сколько соединений со временем.
Вероятно, имеется готовый инструмент, который также может делать такие вещи, но объем кода, необходимый для применения этой техники, в большинстве случаев очень минимален (при условии, что у вас есть простой способ поменять нашу базу фабрика соединений без поиска-замены всей вашей кодовой базы).