Имах точно същия проблем. Трябваше да поддържам активна 1 връзка за 3 нишки и в същото време всяка нишка трябваше да изпълни много оператори (от порядъка на 100k). Бях много внимателен и затворих всяко изявление и всеки набор от резултати, използвайки опит....най-накрая... алгоритъм. По този начин, дори ако кодът се провали по някакъв начин, операторът и наборът от резултати винаги са били затворени. След като изпълних кода в продължение на 8 часа, бях изненадан да открия, че необходимата памет премина от първоначалните 35MB на 500MB. Генерирах дъмп на паметта и го анализирах с Mat Analyzer от Eclipse. Оказа се, че един обект com.mysql.jdbc.JDBC4Connection отнема 445MB памет, поддържайки живи някои openStatements обекти, които от своя страна поддържат живи около 135k записа на хешмап, вероятно от всички резултативни набори. Така че изглежда, че дори да затворите всичките си изрази и набори от резултати, ако не затворите връзката, тя запазва препратки към тях и GarbageCollector не може да освободи ресурсите.
Моето решение :след дълго търсене намерих това изявление от момчетата от MySQL:
„Бърз тест е да добавите „dontTrackOpenResources=true " към вашия JDBC URL. Ако паметта изтече, някакъв кодов път във вашето приложение не затваря оператори и набори от резултати."
Ето връзката:http://bugs.mysql.com/bug.php? id=5022 . Така че опитах това и познайте какво? След 8 часа ми бяха необходими около 40 MB памет за същите операции с база данни. Може би би било препоръчително да има пул за връзки, но ако това не е опция, това е следващото най-добро нещо, което ми се случи.
