Hay varias maneras en que los desarrolladores pueden ser atrapados por filtraciones de recursos involuntarias en .NET. Pensé que sería útil reunirlos en un solo lugar..NET Resource Leak Gotchas
Por favor, añada la suya con una respuesta por tema, por lo que la mejor get votó a :)
Dejando las conexiones de base de datos abierta.
Fallo de implementación Elimine y por lo tanto no elimine objetos secundarios.
O, implementándolo, y no poniendo código en un bloque Using. –
O implementando Dispose pero no agregando un Finalizer que llama a Dispose. –
Manijas del token de suplantación que quedan abiertas.
P/Invocando al código no administrado, y no limpiándolos, o no implementando IDisposable para limpiarlos.
No se eliminaron los controladores de eventos.
El registro para un evento debe ser emparejado con un-registro:
this.myObject.MyEvent += new EventHandler(myObject_MyEvent);
this.myObject.MyEvent -= new EventHandler(myObject_MyEvent);
No es un ejemplo de un sistema en el que esto ocurrió el CodeProject.
No se pudo llamar al método 'Cerrar' en el objeto System.Windows.Window.
La única forma de garantizar que todos los recursos gestionados para un objeto System.Windows.Window sean basura es llamar al método 'Cerrar()' en el objeto Ventana. Llamar a Dispose o establecer la referencia del objeto a null no destruirá el objeto.
¿Puede proporcionar una cita para esto? –
@John: Esto fue encontrado por un colega mío durante una búsqueda de fuga de recursos, por lo que no tengo una referencia publicada. –
Si cuenta la memoria administrada como un "recurso", no desenganchar controladores de eventos es una fuente común de pérdidas de memoria (y varios otros errores más graves).
La memoria administrada no es un recurso, pero sí suscripciones a eventos. – supercat
Listas estáticas, diccionarios y recursos basados en colecciones que se completan fuera del código de inicio.
Esto puede suceder si tiene un diccionario que utiliza como un caché global en lugar de un caché basado en LRU adecuado.
Cualquier cosa estática requiere mucha precaución adicional!
Casi todo al utilizar las API de Office. Como son todos objetos COM, deben eliminarse. También debe mantener una referencia de clase para ellos si desea usar controladores de eventos, de lo contrario, perderán su referencia. En muchos casos, incluso tiene que llamar manualmente al GC para limpiar los objetos
Los objetos del cliente WCF no funcionan como otros objetos IDisposables. El cliente de un servicio WCF debe interrumpirse si la operación está en estado de falla o mantendrá la conexión abierta. Esto generalmente se aprende de la manera difícil.
WCF me quemó con un problema similar recientemente. Lo publicaré pero implicaba llamar a Dispose en la fábrica, lo que implementa IDispose. –
No se usa Using.
El uso de WeakReference puede ocasionar la sutil fuga en la que se limpia el objeto mantenido por WeakReference porque no tiene referencias sólidas, pero la WeakReference en sí misma no se debe a que guarde una referencia fuerte.
Puede encontrarlo si tiene algo así como una Lista o un Diccionario de WeakReferences que nunca borra. Terminarás filtrando objetos WeakReference incluso después de que el objetivo haya sido recolectado.
No se eliminaron objetos relacionados con el dibujo (Gráficos, Fuentes, SolidBrush, Pen, etc.) en .NET Compact Framework. Esto puede causar algunas pérdidas de memoria graves cuando no lo desee (dispositivo móvil = memoria limitada).
Fácil pérdida de memoria: crea un campo estático en una clase de tipo Lista. Agregar elementos a la lista. Nunca recibirán basura recolectada, así que a menos que recuerde eliminar manualmente sus artículos cuando haya terminado con ellos, la memoria está permanentemente atada.
WPF resource dictionary leaks. Algunos enlaces útiles:
desconfigurándolos Spring.NET para crear varias instancias de algo que debería ser un producto único.
Error al llamar a Dispose() en Timer
Post relacionados: http://stackoverflow.com/questions/20386/memory-leaks-in-net –
¿No debería ser esto Wiki de la Comunidad!?!? –
No en CW: que sea recompensado por plantear la pregunta. Buena pregunta, por cierto. – ine