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