Me lo segno da vedere! Jack e' un grande. Personalmente mi capita una due volte l'anno in media di investigare veri o presunti memory leaks e conoscendo la code base di solito ci vuole qualche ora per capire.
Ho fatto quest'anno il seminario con Kirk Pepperdine che per mestiere fa questo su code bases che non conosce e spesso scritte malissimo. A lui bastano 5 minuti in genere per capire il problema ma poi serve un meeting di 5 ore col cliente per spiegarglielo. :) Effettivamente ci sono un mucchio di tool potentissimi nel env java che non conoscevo. Uberto On Thu, 6 Jun 2019 at 22:11, Marco Bartolini [email protected] [it-torino-java-jug] <[email protected]> wrote: > > > ho sempre usato un mix di tool, ma al DevoXX quest anno hanno presentato > per bene un debug > > https://www.youtube.com/watch?v=JoQN4xoXY5Y > > On Thu, 6 Jun 2019 at 00:18, Uberto Barbini [email protected] > [it-torino-java-jug] <[email protected]> wrote: > >> >> >> Un altro paio di considerazioni: >> In Java quelli che chiamiamo memory leaks in realta' di solito sono solo >> allocazioni di memoria di cui ci siamo "dimenticati". >> Per esempio thread orfani che restano appesi (con tutti i loro oggetti) o >> cache che non vengono svuotate regolarmente. >> Le eccezioni sono bugs nella JVM (ogni tanto ce n'e' qualcuno) e >> allocazioni JNI. >> Un altro caso che puo' dare problemi e' una super allocazione di memoria >> di picco che sfora l'heap prima che il GC possa ripulire. >> Pero' non mi sembra il caso qui. >> >> Un altro tool utile per fare investigazioni sulla memoria e' MAT di >> Eclipse, e' indipendente dall'IDE e se mi ricordo bene ha anche un bottone >> "scopri memory leaks" che fa un po' di euristiche niente male. >> https://www.eclipse.org/mat/ >> >> Uberto >> >> On Wed, 5 Jun 2019 at 21:06, Uberto Barbini <[email protected]> >> wrote: >> >>> Per trovare il memory leak in fretta ti basta fare un memory dump con >>> l'applicazione che gira da un po' e poi guardarci con visualvm. >>> I casi più semplici li trovi cercando le classi tue con più istanze. >>> >>> Metodi più sofisticati richiedono analizzare i log del gc, ma di solito >>> lo vedi da visualvm >>> >>> Uberto >>> >>> On Wed, 5 Jun 2019, 15:36 Salvatore Spoto [email protected] >>> [it-torino-java-jug], <[email protected]> wrote: >>> >>>> >>>> >>>> Ciao a tutti, >>>> avrei la necessità di trovare dei memory leak in un'applicazione java. >>>> >>>> Il sintomo è abbastanza banale: la memoria cresce costantemente nel >>>> tempo, senza essere mai liberata, e questo porta il processo ad essere >>>> ucciso quando raggiunge i limiti di memoria pre determinati del container >>>> (l'applicazione gira in un docker). >>>> >>>> Qualcuno saprebbe consigliari dei profiler, tool o best practice per >>>> eseguire questo lavoro ? >>>> >>>> Ho visto che vi sono JProfile e YourKit, purtroppo sono commerciali, ma >>>> sembrano ottimi. Anche lo stesso Java Mission Control credo che richieda >>>> una licenza per essere usato in ambienti di produzione. Forse di >>>> quest'ultimo vi è una versione open source sulla jdk 11, ma io sto >>>> lavorando ancora sulla 7 :_/. >>>> >>>> Grazie delle dritte.... >>>> >>>> Ciao, >>>> Salvatore >>>> >>>> >
