Eu tive exatamente o mesmo problema. Eu precisava manter 1 conexão ativa para 3 threads e ao mesmo tempo cada thread tinha que executar muitas instruções (da ordem de 100k). Fui muito cuidadoso e fechei cada declaração e cada conjunto de resultados usando um algoritmo try....finalmente.... Dessa forma, mesmo que o código falhe de alguma forma, a instrução e o conjunto de resultados sempre foram fechados. Depois de executar o código por 8 horas, fiquei surpreso ao descobrir que a memória necessária passou dos 35 MB iniciais para 500 MB. Gerei um dump da memória e analisei com o Mat Analyzer do Eclipse. Descobriu-se que um objeto com.mysql.jdbc.JDBC4Connection estava consumindo 445 MB de memória mantendo vivos alguns objetos openStatements que por sua vez mantinham vivos cerca de 135k entradas de hashmap, provavelmente de todos os conjuntos de resultados. Então parece que mesmo se você fechar todas as suas declarações e conjuntos de resultados, se você não fechar a conexão, ele mantém referências a eles e o GarbageCollector não pode liberar os recursos.

Minha solução :depois de uma longa pesquisa, encontrei esta declaração dos caras do MySQL:

"Um teste rápido é adicionar "dontTrackOpenResources=true " para sua URL JDBC. Se a memória vazar, algum caminho de código em seu aplicativo não está fechando instruções e conjuntos de resultados."

Aqui está o link:http://bugs.mysql.com/bug.php? código=5022 . Então eu tentei isso e adivinhem? Após 8 horas, eu precisava de cerca de 40 MB de memória, para as mesmas operações de banco de dados. Talvez um pool de conexão fosse aconselhável, mas se isso não for uma opção, essa é a próxima melhor coisa que encontrei.