Miałem dokładnie ten sam problem. Musiałem utrzymać aktywne 1 połączenie dla 3 wątków i jednocześnie każdy wątek musiał wykonywać wiele instrukcji (rzędu 100k). Byłem bardzo ostrożny i zamykałem każde stwierdzenie i każdy zestaw wyników za pomocą algorytmu try…finally…. W ten sposób, nawet jeśli kod zawiódł w jakiś sposób, instrukcja i zestaw wyników były zawsze zamknięte. Po uruchomieniu kodu przez 8 godzin z zaskoczeniem stwierdziłem, że potrzebna pamięć wzrosła z początkowych 35 MB do 500 MB. Wygenerowałem zrzut pamięci i przeanalizowałem go za pomocą Mat Analyzer z Eclipse. Okazało się, że jeden obiekt com.mysql.jdbc.JDBC4Connection zajmował 445 MB pamięci, utrzymując przy życiu niektóre obiekty openStatements, które z kolei utrzymywały przy życiu około 135 tys. wpisów hashmap, prawdopodobnie ze wszystkich zestawów wyników. Wygląda więc na to, że nawet jeśli zamkniesz wszystkie instrukcje i zestawy wyników, jeśli nie zamkniesz połączenia, zachowa on do nich odniesienia, a GarbageCollector nie zwolni zasobów.
Moje rozwiązanie :po długich poszukiwaniach znalazłem to oświadczenie od chłopaków z MySQL:
„Szybki test polega na dodaniu „dontTrackOpenResources=true " do adresu URL JDBC. Jeśli przeciek pamięci zniknie, jakaś ścieżka kodu w aplikacji nie zamyka instrukcji i zestawów wyników."
Oto link:http://bugs.mysql.com/bug.php? id=5022 . Więc spróbowałem i zgadnij co? Po 8 godzinach potrzebowałem około 40 MB pamięci na te same operacje na bazie danych. Może pula połączeń byłaby wskazana, ale jeśli to nie jest opcja, to jest to kolejna najlepsza rzecz, z jaką się spotkałem.
