我试图在我们的一个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资源,但是找不到导致这种情况的原因.
抓住它有什么好办法吗？你有没有经历过这个,并建议我应该寻找什么？
P.S：
通过MAT深入了解,我看到以下信息：
com.MysqL.jdbc.JDBC4Connection @ 0x2aaab64ad820 | 1,856 | 87,160 | 8.28％
| – java.util.HashMap @ 0x2aaab62115a8 | 64 | 87,021,632 | 8.27％
| ‘ – java.util.HashMap $Entry [16384] @ 0x2aaae182e970 | 131,096 | 87,568 | 8.27％
似乎每个JDBC都拥有大量的Hashmap条目(> 6000个对象),并且根本不释放它们.
提前致谢！
最佳答案
达夫莫几乎肯定是对的.在过去,当我们有内存泄漏时,它实际上总是MysqL JDBC驱动程序.忘记在某处关闭一个小ResultSet或Connection或Statement.每次我们使用它们来查找问题并确保它们关闭时,我最终都会审核整个代码库.
至于HashMap,我也看过了.我没有查看源代码,但我的印象是MysqL驱动程序在内部存储了HashMaps中的行(至少是行值).
泄漏的ResultSet很容易.由于这个原因,在JDK 7或8中自行处理这些可靠资源的想法确实吸引了我.
您可以在某处插入一个垫片类(比如连接)来记录每个打开/关闭的资源,看看是否可以捕获泄漏的位置,而无需直接读取所有源.