Ho avuto esattamente lo stesso problema. Avevo bisogno di mantenere attiva 1 connessione per 3 thread e allo stesso tempo ogni thread doveva eseguire molte istruzioni (l'ordine di 100k). Sono stato molto attento e ho chiuso ogni istruzione e ogni set di risultati usando un algoritmo try....finalmente... In questo modo, anche se il codice falliva in qualche modo, l'istruzione e il set di risultati venivano sempre chiusi. Dopo aver eseguito il codice per 8 ore, sono rimasto sorpreso di scoprire che la memoria necessaria è passata dai 35 MB iniziali a 500 MB. Ho generato un dump della memoria e l'ho analizzato con Mat Analyzer di Eclipse. Si è scoperto che un oggetto com.mysql.jdbc.JDBC4Connection stava occupando 445 MB di memoria mantenendo in vita alcuni oggetti openStatements che a loro volta mantenevano in vita circa 135.000 voci hashmap, probabilmente da tutti i set di risultati. Quindi sembra che anche se chiudi tutte le tue istruzioni e i set di risultati, se non chiudi la connessione, mantiene i riferimenti ad esse e GarbageCollector non può liberare le risorse.
La mia soluzione :dopo una lunga ricerca ho trovato questa dichiarazione dei ragazzi di MySQL:
"Un test rapido consiste nell'aggiungere "dontTrackOpenResources=true " all'URL JDBC. Se la perdita di memoria scompare, alcuni percorsi di codice nell'applicazione non stanno chiudendo le istruzioni e i set di risultati."
Ecco il link:http://bugs.mysql.com/bug.php? id=5022 . Quindi l'ho provato e indovina un po'? Dopo 8 ore avevo bisogno di circa 40 MB di memoria, per le stesse operazioni di database. Forse un pool di connessioni sarebbe consigliabile, ma se questa non è un'opzione, questa è la prossima cosa migliore che ho trovato.
