Ci sono diversi modi in cui gli sviluppatori possono essere scoperti da perdite di risorse non intenzionali in .NET. Ho pensato che sarebbe stato utile riunirli in un unico posto.Gettati di perdite di risorse .NET
Si prega di aggiungere il vostro con una sola risposta per ogni articolo, quindi il miglior get votato fino :)
Lasciando le connessioni al database aperto.
Mancata implementazione di Dispose e quindi non smaltimento di oggetti figlio.
Oppure, implementandolo e non inserendo il codice in un blocco Using. –
Oppure implementare Dispose ma non aggiungere un Finalizer che chiama Dispose. –
Maniglie token di identità lasciate aperte.
P/Richiamando al codice non gestito e non pulendolo, o non implementando IDisposable per farlo ripulire.
Errore di rimozione dei gestori di eventi.
registrazione di un evento dovrebbe essere accoppiato con un-registrazione:
this.myObject.MyEvent += new EventHandler(myObject_MyEvent);
this.myObject.MyEvent -= new EventHandler(myObject_MyEvent);
V'è un esempio di un sistema in cui questo è accaduto su CodeProject.
Errore nel chiamare il metodo "Chiudi" nell'oggetto System.Windows.Window.
L'unico modo per garantire che tutte le risorse gestite per un oggetto System.Windows.Window siano garbage collection è chiamare il metodo 'Close()' sull'oggetto Window. Chiamare Dispose o impostare il riferimento all'oggetto su null non distruggerà l'oggetto.
Potete fornire una citazione per questo? –
@John: questo è stato rilevato da un mio collega durante una ricerca di perdita di risorse, quindi non ho un riferimento pubblicato. –
Se si conta la memoria gestita come una "risorsa", il mancato scollamento dei gestori di eventi è una fonte comune di perdite di memoria (e vari altri bug più gravi).
La memoria gestita non è una risorsa, ma gli abbonamenti agli eventi lo sono. – supercat
Elenchi statici, dizionari e risorse basate su raccolte popolate al di fuori del codice di avvio.
Ciò può accadere se si dispone di un dizionario che si utilizza come cache globale anziché di una cache basata su LRU corretta.
Qualsiasi cosa statico richiede molta cautela!
Praticamente tutto quando si utilizzano le API di Office. Poiché sono tutti oggetti COM, devono essere eliminati. Devi anche tenere un riferimento di classe ad essi se vuoi usare i gestori di eventi, altrimenti perdono il loro riferimento. In molti casi, è necessario chiamare manualmente il GC per pulire gli oggetti
Gli oggetti client WCF non funzionano come altri oggetti IDisposable. Il client di un servizio WCF deve essere interrotto se l'operazione è in uno stato di errore, altrimenti manterrà aperta la connessione. Questo di solito è imparato nel modo più duro.
WCF mi ha bruciato di recente con un problema simile. Lo posterò, ma ha coinvolto la chiamata a Dispose in fabbrica - che implementa IDispose! –
Non in uso Using.
L'utilizzo di un WeakReference può portare alla perdita sottile in cui l'oggetto trattenuto da WeakReference viene ripulito perché non ha riferimenti forti, ma il WeakReference non lo è perché si mantiene un forte riferimento ad esso.
È possibile imbattersi in questo se si dispone di qualcosa come un elenco o un dizionario di WeakReferences che non si sfoltire mai. Finirai per perdere oggetti WeakReference anche dopo che il target è stato raccolto.
Mancato smaltimento di oggetti relativi al disegno (Grafica, Font, SolidBrush, Penna, ecc.) In .NET Compact Framework. Ciò può causare alcune gravi perdite di memoria quando non si desidera (dispositivo mobile = memoria limitata).
Perdita di memoria facile: creare un campo statico in una classe di tipo Elenco. Aggiungi elementi alla lista. Non riceveranno mai i rifiuti raccolti, quindi a meno che non ti ricordi di rimuovere manualmente i tuoi oggetti quando hai finito con loro, la memoria è legata in modo permanente.
Perdite nel dizionario delle risorse WPF. Alcuni link utili:
misconfiguring Spring.NET per creare più istanze di qualcosa che dovrebbe essere un Singleton.
Impossibile chiamare Dispose() su Timer
Post correlati: http://stackoverflow.com/questions/20386/memory-leaks-in-net –
Non dovrebbe essere questo Wiki!?!? –
No on CW - lascia che sia ricompensato per aver sollevato la domanda. Bella domanda, a proposito. – ine