JDBC4Connection中的內存泄漏

Question

我試圖在我們的一個Java守護進程中捕獲內存泄漏，在轉儲內存並通過Memory Analyzer Tool進行分析之后，注意到大部分泄漏是由JDBC4Connection引起的：

10 instances of "com.mysql.jdbc.JDBC4Connection", loaded by "sun.misc.Launcher$AppClassLoader @ 0x2aaab620ed00" occupy 858,283,752 (81.55%) bytes. Biggest instances:

* com.mysql.jdbc.JDBC4Connection @ 0x2aaab64ad820 - 87,110,160 (8.28%) bytes.
* com.mysql.jdbc.JDBC4Connection @ 0x2aaab64af520 - 86,730,408 (8.24%) bytes.
* com.mysql.jdbc.JDBC4Connection @ 0x2aaab64ad0e0 - 86,584,048 (8.23%) bytes.
* com.mysql.jdbc.JDBC4Connection @ 0x2aaab64aede0 - 86,488,800 (8.22%) bytes.
* com.mysql.jdbc.JDBC4Connection @ 0x2aaab61f5320 - 85,752,872 (8.15%) bytes.
* com.mysql.jdbc.JDBC4Connection @ 0x2aaab64ae6a0 - 85,603,280 (8.13%) bytes.
* com.mysql.jdbc.JDBC4Connection @ 0x2aaab64adf60 - 85,270,440 (8.10%) bytes.
* com.mysql.jdbc.JDBC4Connection @ 0x2aaab61f4be0 - 85,248,592 (8.10%) bytes.
* com.mysql.jdbc.JDBC4Connection @ 0x2aaab64afc60 - 85,120,704 (8.09%) bytes.
* com.mysql.jdbc.JDBC4Connection @ 0x2aaab61f5a60 - 84,374,448 (8.02%) bytes.

Keywords
com.mysql.jdbc.JDBC4Connection
sun.misc.Launcher$AppClassLoader @ 0x2aaab620ed00

我很確定我們關閉了所有的MySQL資源，但是找不到導致這種情況的原因。

抓住它有什么好辦法嗎？ 你有沒有經歷過這個，並建議我應該尋找什么？

PS：深入了解MAT，我看到以下信息：

com.mysql.jdbc.JDBC4Connection @ 0x2aaab64ad820 | 1,856 | 87,110,160 | 8.28% |- java.util.HashMap @ 0x2aaab62115a8 | 64 | 87,021,632 | 8.27% | '- java.util.HashMap$Entry[16384] @ 0x2aaae182e970| 131,096 | 87,021,568 | 8.27%

似乎每個JDBC都擁有大量的Hashmap條目（> 6000個對象），並且根本不釋放它們。

提前致謝！

Answer 1

達夫莫幾乎肯定是對的。 在過去，當我們有內存泄漏時，它實際上總是MySQL JDBC驅動程序。 忘記在某處關閉一個小ResultSet或Connection或Statement。 每次我們使用它們來查找問題並確保它們關閉時，我最終都會審核整個代碼庫。

至於HashMap，我也看過了。 我沒有查看源代碼，但我的印象是MySQL驅動程序在內部存儲了HashMaps中的行（至少是行值）。

泄漏的ResultSet很容易。 由於這個原因，在JDK 7或8中自行處理這些可靠資源的想法確實吸引了我。

您可以在某處插入一個墊片類（比如連接）來記錄每個打開/關閉的資源，看看是否可以捕獲泄漏的位置，而無需直接讀取所有源。

Answer 2

我很確定我們關閉了所有的MySQL資源

如果不是100％確定，請說明您是如何關閉連接的。

你在使用連接池嗎？ 它的碰巧會有10個游泳池嗎？

Answer 3

聽起來你有一個連接池有10個連接，並且池啟用了語句緩存，沒有將緩存大小限制為健康數量。