Anatomía de una " Fuga de memoria"

Estrictamente hablando, una fuga de memoria está consumiendo memoria que "ya no es utilizada" por el programa.

"No longer used" tiene más de un significado, podría significar "no más referencia a él", es decir, totalmente irrecuperable, o podría significar, referenciado, recuperable, sin usar, pero el programa mantiene las referencias de todos modos. Solo esto último se aplica a. Net para objetos perfectamente administrados. Sin embargo, no todas las clases son perfectas y en algún momento una implementación subyacente no administrada podría filtre recursos permanentemente para ese proceso.

En todos los casos, la aplicación consume más memoria de la estrictamente necesaria. Los efectos secundarios, dependiendo de la cantidad filtrada, podrían ir de ninguno, a la desaceleración causada por la recolección excesiva, a una serie de excepciones de memoria y, finalmente, un error fatal seguido de terminación forzada del proceso.

Sabe que una aplicación tiene un problema de memoria cuando el monitoreo muestra que se asigna más y más memoria a su proceso después de cada ciclo de recolección de basura . En tal caso, o bien está guardando demasiado en la memoria, o alguna implementación subyacente no administrada se está filtrando.

Para la mayoría de las fugas, los recursos se recuperan cuando se termina el proceso, sin embargo, algunos recursos no siempre se recuperan en algunos casos precisos, los controladores de cursor GDI son notorios por eso. Por supuesto, si tiene un mecanismo de comunicación entre procesos, la memoria asignada en el otro proceso no se liberará hasta que ese proceso la libere o termina.

Creo que las preguntas "qué es una fuga de memoria" y "cuáles son los efectos" ya han sido respondidas bien, pero quería agregar algunas cosas más sobre las otras preguntas...

Cómo entender, si su aplicación fugas

Una forma interesante es abrir perfmon y agregar trazas para # bytes en todos los montones y # colecciones Gen 2 , en cada caso mirando solo su proceso. Si el ejercicio de una característica particular hace que el total de bytes aumentar, y que la memoria permanece asignado después de la próxima generación 2 colección, se podría decir que la característica fugas de memoria.

Cómo prevenir

Se han dado otras buenas opiniones. Solo agregaría que quizás la causa más comúnmente ignorada de las fugas de memoria de.NET es agregar controladores de eventos a los objetos sin eliminarlos. Un controlador de eventos adjunto a un objeto es una forma de referencia a ese objeto, por lo que evitará la recopilación incluso después de todos los demás las referencias se han ido. Recuerde siempre separar los controladores de eventos (usando la sintaxis -= en C#).

¿La fuga desaparece cuando sale el proceso, y qué pasa con la interop COM?

Cuando el proceso sale, toda la memoria asignada a su espacio de direcciones es reclamada por el sistema operativo, incluyendo cualquier objeto COM servido desde DLL. Comparativamente rara vez, los objetos COM se pueden servir desde procesos separados. En este caso, cuando finalice el proceso, es posible que aún sea responsable de la memoria asignado en cualquier proceso de servidor COM que haya utilizado.

Definiría fugas de memoria como un objeto que no libera toda la memoria asignada después de que se haya completado. He encontrado que esto puede suceder en su aplicación si está utilizando la API de Windows y COM (es decir, código no administrado que tiene un error o no se administra correctamente), en el marco y en componentes de terceros. También he encontrado que no hacer tiding después de usar ciertos objetos como bolígrafos puede causar el problema.

Personalmente he sufrido Excepciones de Memoria que pueden ser causadas pero no son exclusivos de las fugas de memoria en las aplicaciones dot net. (OOM también puede venir de fijación ver Fijación Artical ). Si no está obteniendo errores de OOM o necesita confirmar si se trata de una fuga de memoria que lo causa, entonces la única manera es perfilar su aplicación.

También trataría de asegurar lo siguiente:

A) Todo lo que implementa Idesposable se dispone utilizando un bloque finally o la instrucción using estos incluyen pinceles, bolígrafos, etc.(algunas personas argumentan para establecer de todo a nada además)

B) Cualquier cosa que tenga un método close se cierra de nuevo usando finally o la instrucción using (aunque he encontrado que usar no siempre se cierra dependiendo de si declaraste el objeto fuera de la instrucción using)

C)Si está utilizando código no administrado/API de Windows que estos se tratan correctamente después. (algunos tienen métodos de limpieza para liberar recursos)

Espero que esto ayude.

Si necesita diagnosticar una fuga de memoria en. NET, compruebe estos enlaces:

Http://msdn.microsoft.com/en-us/magazine/cc163833.aspx

Http://msdn.microsoft.com/en-us/magazine/cc164138.aspx

Esos artículos describen cómo crear un volcado de memoria de su proceso y cómo analizarlo para que primero pueda determinar si su fuga no está administrada o administrada, y si se administra, cómo averiguar de dónde viene.

Microsoft también tiene un nuevo herramienta para ayudar a generar volcados de bloqueo, para reemplazar ADPlus, llamado DebugDiag.

Http://www.microsoft.com/downloads/details.aspx?FamilyID=28bd5941-c458-46f1-b24d-f60151d875a3&displaylang=en

Usando CLR Profiler de Microsoft http://www.microsoft.com/downloads/details.aspx?familyid=86ce6052-d7f4-4aeb-9b7a-94635beebdda&displaylang=en es una gran manera de determinar qué objetos tienen memoria, qué flujo de ejecución conduce a la creación de estos objetos, y también monitorear qué objetos viven en dónde en el montón (fragmentación, LOH, etc.).

La mejor explicación de cómo funciona el recolector de basura está en Jeff Richters CLR vía C# book, (Ch. 20). Leer esto proporciona una gran base para comprender cómo persisten los objetos.

Una de las causas más comunes de rootear objetos accidentalmente es al conectar eventos outisde una clase. Si conecta un evento externo

Por ejemplo

SomeExternalClass.Changed += new EventHandler(HandleIt);

Y olvídate de desengancharlo cuando te deshagas, entonces alguna clase externa tiene una referencia para tu clase.

Como se mencionó arriba, el SciTech memory profiler es excelente para mostrarle las raíces de los objetos que sospecha que se están filtrando.

Pero también hay una forma muy rápida de comprobar un tipo particular es simplemente usar WnDBG (incluso puede usar esto en el VS.NET ventana inmediata mientras está conectada):

.loadby sos mscorwks
!dumpheap -stat -type <TypeName>

Ahora haz algo que creas que eliminará los objetos de ese tipo (por ejemplo, cierra una ventana). Es útil aquí tener un botón de depuración en algún lugar que se ejecute System.GC.Collect() un par de veces.

Entonces ejecute !dumpheap -stat -type <TypeName> de nuevo. Si el número no fue, o no fue tanto como se puede esperar, entonces usted tiene una base para futuras investigaciones. (Recibí este consejo de un seminario dado por Ingo Rammer ).

Supongo que en un entorno gestionado, una fuga sería mantener una referencia innecesaria a una gran parte de la memoria alrededor.

¿Por qué la gente piensa que una fuga de memoria en. NET no es lo mismo que cualquier otra fuga?

Una fuga de memoria es cuando se conecta a un recurso y no lo deja ir. Puede hacer esto tanto en la codificación administrada como en la no administrada.

Con respecto a.NET y otras herramientas de programación, ha habido ideas sobre la recolección de basura y otras formas de minimizar las situaciones que harán que su aplicación se filtre. Pero el mejor método para prevenir fugas de memoria es que usted necesita entender su modelo de memoria subyacente, y cómo funcionan las cosas, en la plataforma que está utilizando.

Creer que GC y otra magia limpiarán su desorden es el camino corto a las fugas de memoria, y será difícil de encontrar más adelante.

Al codificar sin administrar, normalmente te aseguras de limpiar, sabes que los recursos que tomas, serán tu responsabilidad de limpiar, no la del conserje.

En.NET por otro lado, mucha gente piensa que el GC limpiará todo. Bien, hace algo por ti, pero necesitas asegurarte de que así sea. . NET envuelve muchas cosas, por lo que no siempre sabe si está tratando con un recurso administrado o no administrado, y necesita asegurarse de con qué está tratando. El manejo de fuentes, recursos de GDI, active directory, bases de datos, etc. son cosas que normalmente debe tener en cuenta.

En términos manejados voy a poner mi cuello en la línea para decir que se va una vez el proceso es eliminado eliminado.

Ya veo sin embargo, mucha gente tiene esto, y realmente espero que esto termine. ¡No puedes pedirle al usuario que termine tu aplicación para limpiar tu desastre! Echa un vistazo a un navegador, que puede ser IE, FF, etc, a continuación, abrir, por ejemplo, Google Reader, dejar que se quede durante algunos días, y mira lo que sucede.

Si luego abre otra pestaña en el navegador, navega a algún sitio, luego cierra la pestaña que alojó la otra página que hizo que el navegador se filtrara, ¿cree que el navegador liberará la memoria? No es así con IE. En mi computer IE comerá fácilmente 1 GiB de memoria en un corto período de tiempo (aproximadamente 3-4 días) si uso Google Reader. Algunos periódicos son aún peores.

Supongo que en un entorno gestionado, un fuga sería usted mantener un referencia innecesaria a un trozo grande de la memoria.

Absolutamente. Además, no usar el.El método Dispose() en objetos desechables cuando sea apropiado puede causar fugas de mem. La forma más fácil de hacerlo es con un bloque using porque se ejecuta automáticamente .Dispose () al final:

StreamReader sr;
using(sr = new StreamReader("somefile.txt"))
{
    //do some stuff
}

Y si crea una clase que está utilizando objetos no administrados, si no está implementando Identificable correctamente, podría estar causando fugas de memoria para los usuarios de su clase.

Estoy de acuerdo con Bernard en lo que sería una filtración de mem en.net.

Podría perfilar su aplicación para ver su uso de memoria, y determinar que si está administrando mucha memoria cuando no debería, podría decir que tiene una fuga.

En términos manejados pondré mi cuello en la línea para decir que desaparece una vez que el proceso es asesinado/eliminado.

El código no administrado es su propia bestia y si existe una fuga dentro de ella, seguirá un mem estándar. definición de fuga.

Todas las fugas de memoria se resuelven mediante la terminación del programa.

Filtre suficiente memoria y el Sistema Operativo puede decidir resolver el problema en su nombre.

También tenga en cuenta que.NET tiene dos montones, uno es el montón de objetos grandes. Creo que los objetos de aproximadamente 85k o más grandes se ponen en este montón. Este montón tiene unas reglas de vida diferentes que el montón normal.

Si está creando grandes estructuras de memoria (Diccionarios o Listas) sería prudente buscar cuáles son las reglas exactas.

En cuanto a la recuperación de la memoria en la terminación del proceso, a menos que su Win98 en ejecución o sus equivalentes, todo se libera de nuevo al sistema operativo en la terminación. Las únicas excepciones son las cosas que se abren entre procesos y otro proceso todavía tiene el recurso abierto.

Los objetos COM pueden ser complicados. Si siempre usas el patrón IDispose, estarás a salvo. Pero me he encontrado con algunos ensamblajes de interop que implementan IDispose. La clave aquí es llamar Marshal.ReleaseCOMObject cuando haya terminado con él. Los objetos COM todavía utilizan el conteo de referencia COM estándar.

He encontrado . Net Memory Profiler una muy buena ayuda al encontrar fugas de memoria en. Net.No es gratis como el Microsoft CLR Profiler, pero es más rápido y más al punto en mi opinión. A

Una definición es: No se puede liberar memoria inalcanzable, que ya no se puede asignar a un nuevo proceso durante la ejecución del proceso de asignación. En su mayoría se puede curar mediante el uso de técnicas de GC o detectado por herramientas automatizadas.

Para obtener más información, visite http://all-about-java-and-weblogic-server.blogspot.in/2014/01/what-is-memory-leak-in-java.html.