I due principali modelli di "efficace perdite" Nella mia esperienza sono:
- Statica e single che gradualmente crescere nel tempo. Ciò potrebbe includere cache, pool di connessioni mal implementate e utilizzate, dizionari di "ogni utente visto dall'avvio" ecc.
- I riferimenti da oggetti longevi a oggetti che erano destinati a sono di breve durata. In C# questo può accadere con gli eventi, e il modello di osservatore equivalente potrebbe dare lo stesso tipo di effetto in Java. Fondamentalmente se si chiede a un oggetto (l'osservatore) di guardare un altro (la fonte), di solito si ottiene un riferimento da alla sorgente a l'osservatore. Questo può finire per essere l'unico riferimento "vivo", ma vivrà finché la fonte.
- Permeano perdite se si continua a generare un nuovo codice in modo dinamico. Sono su un terreno più rock qui, ma sono abbastanza sicuro che mi sono imbattuto in problemi in questo modo. È possibile che ciò sia dovuto in parte ai bug di JRE che sono stati riparati - è passato troppo tempo da quando è successo che me lo ricordi per certo.
- I test di unità che rimangono su uno stato possono durare più a lungo di quanto ci si potrebbe aspettare perché JUnit manterrà le istanze del testcase. Ancora una volta non riesco a ricordare i dettagli, ma a volte questo rende meritevole l'esplicita "nullizzazione delle variabili" nel teardown, anacronistico come sembra.
Non posso dire di aver trovato regolarmente perdite di memoria come problemi in Java (o .NET).
fonte
2009-03-22 10:15:33
Oh, vedo che questo accade abbastanza spesso se usi le chiusure del povero. Non ti stai rendendo conto di stare aggrappato all'oggetto esterno e a tutti i suoi riferimenti. Questo si sporca * veramente * velocemente. – krosenvold