私はまったく同じ問題を抱えていました。 3つのスレッドに対して1つの接続をアクティブに保つ必要があり、同時にすべてのスレッドが多くのステートメント（100kのオーダー）を実行する必要がありました。私は非常に注意深く、try ....final...アルゴリズムを使用してすべてのステートメントとすべての結果セットを閉じました。このように、コードが何らかの方法で失敗した場合でも、ステートメントと結果セットは常に閉じられていました。コードを8時間実行した後、必要なメモリが最初の35MBから500MBに増えたことに驚きました。メモリのダンプを生成し、EclipseのMatAnalyzerで分析しました。 1つのcom.mysql.jdbc.JDBC4Connectionオブジェクトが445MBのメモリを使用して、いくつかのopenStatementsオブジェクトを保持し、135kのハッシュマップエントリ（おそらくすべての結果セットから）を保持していることが判明しました。したがって、すべてのステートメントと結果セットを閉じても、接続を閉じないと、それらへの参照が保持され、GarbageCollectorはリソースを解放できないようです。
私の解決策 ：長い検索の結果、MySQLのメンバーからこのステートメントが見つかりました：
「簡単なテストは、「 dontTrackOpenResources =true」を追加することです。 「JDBCURLに。メモリリークがなくなった場合、アプリケーションの一部のコードパスがステートメントと結果セットを閉じていません。」
リンクは次のとおりです： http://bugs.mysql.com/bug.php？ id =5022 。だから私はそれを試し、何を推測しますか？ 8時間後、同じデータベース操作のために約40MBのメモリが必要になりました。接続プールが表示される可能性がありますが、それが不可能な場合は、これが次善の策です。