Jeg havde præcis det samme problem. Jeg havde brug for at holde 1 forbindelse aktiv i 3 tråde og samtidig skulle hver tråd udføre en masse sætninger (i størrelsesordenen 100k). Jeg var meget forsigtig, og jeg lukkede alle udsagn og hvert resultatsæt ved hjælp af et forsøg ... endelig ... algoritme. På denne måde, selvom koden fejlede på en eller anden måde, var erklæringen og resultatsættet altid lukket. Efter at have kørt koden i 8 timer blev jeg overrasket over at opdage, at den nødvendige hukommelse gik fra de oprindelige 35 MB til 500 MB. Jeg genererede et dump af hukommelsen, og jeg analyserede det med Mat Analyzer fra Eclipse. Det viste sig, at et com.mysql.jdbc.JDBC4Connection-objekt tog 445 MB hukommelse og holdt nogle openStatements-objekter i live, som igen holdt i live omkring 135k hashmap-indgange, sandsynligvis fra alle resultatsættene. Så det ser ud til, at selvom du lukker alle dine udsagn og resultatsæt, hvis du ikke lukker forbindelsen, gemmer den referencer til dem, og GarbageCollector kan ikke frigøre ressourcerne.
Min løsning :efter en lang søgning fandt jeg denne udtalelse fra gutterne på MySQL:
"En hurtig test er at tilføje "dontTrackOpenResources=true " til din JDBC URL. Hvis hukommelsen lækker, lukker en kodesti i din applikation ikke sætninger og resultatsæt."
Her er linket:http://bugs.mysql.com/bug.php? id=5022 . Så jeg prøvede det og gæt hvad? Efter 8 timer krævede jeg omkring 40 MB hukommelse til de samme databaseoperationer. Måske ville en forbindelsespulje være tilrådelig, men hvis det ikke er en mulighed, er dette den næstbedste ting, jeg fandt.