Geek Answers Handbook

JDBC4Connection memory leak

I am trying to catch a memory leak in one of our Java daemons, and after resetting the memory and analyzing it using the Memory Analyzer Tool, I noticed that most of the leak is caused by 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

I am sure that we are closing all MySQL resources, but cannot find the reason for this.

Is there a good way to catch him? Have you experienced this in the past and can advise what I should look for?

PS: Looking deeper into the MAT, I see the following information:

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%

It seems that each JDBC contains a huge number of entries in the Hashmap (> 6000 objects) and does not free them at all.

Thanks in advance!

+5
source share
2 answers

Duffimo is almost right. In the past, when we had memory leaks, it is ALWAYS ALWAYS a MySQL JDBC driver. Just forget to close one small ResultSet or Connection or Statement somewhere. I completed an audit of the entire code base every time we used them to find the problem and make sure they were closed.

As for the HashMap, I saw it too. I did not look at the source, but it seemed to me that the MySQL driver stores the rows (at least the row values) inside the HashMaps inside.

Leaking ResultSets is sadly simple. For this reason, the idea of ​​these private resources, which take care of this themselves, come in JDK 7 or 8, really appeals to me for this reason.

You can insert a gasket class somewhere (for example, to connect) to register each open / closed resource, to find out if you can catch where it flows without directly reading your entire source.

+6
source

I am sure that we are closing all MySQL resources

If you are not 100% sure, please show how you close your connections.

Are you using a connection pool? Would it have a pool size of 10?

+4
source

More articles:


All Articles