Jag hade exakt samma problem. Jag behövde hålla 1 anslutning aktiv för 3 trådar och samtidigt var varje tråd tvungen att köra många satser (i storleksordningen 100k). Jag var mycket försiktig och jag stängde varje påstående och varje resultatuppsättning med ett försök ... äntligen ... algoritm. På detta sätt, även om koden misslyckades på något sätt, stängdes satsen och resultatuppsättningen alltid. Efter att ha kört koden i 8 timmar blev jag förvånad över att finna att det nödvändiga minnet gick från de ursprungliga 35 MB till 500 MB. Jag genererade en dump av minnet och jag analyserade det med Mat Analyzer från Eclipse. Det visade sig att ett com.mysql.jdbc.JDBC4Connection-objekt tog 445 MB minne och höll några openStatements-objekt vid liv som i sin tur höll vid liv runt 135k hashmap-poster, förmodligen från alla resultatuppsättningar. Så det verkar som att även om du stänger alla dina uttalanden och resultatuppsättningar, om du inte stänger anslutningen, behåller den referenser till dem och GarbageCollector kan inte frigöra resurserna.
Min lösning :efter en lång sökning hittade jag detta uttalande från killarna på MySQL:
"Ett snabbt test är att lägga till "dontTrackOpenResources=true " till din JDBC-URL. Om minnet läcker bort stänger inte någon kodsökväg i din applikation programsatser och resultatuppsättningar."
Här är länken:http://bugs.mysql.com/bug.php? id=5022 . Så jag försökte det och gissa vad? Efter 8 timmar behövde jag cirka 40 MB minne för samma databasoperationer. Kanske skulle en anslutningspool vara tillrådlig, men om det inte är ett alternativ är det här det näst bästa jag har hittat.