Pérdidas de memoria y recursos en aplicaciones .NET

Lo siguiente es un (muy) breve resumen de un artículo de la MSDN:

Artículo original

En primer lugar, es vital entender que los lenguajes con recolector de basura como .NET no son inmunes a las pérdidas de memoria. Una de las razones de ello es que el recolector sólo libera memoria que ya no es referenciada: si el contador de referencias de un objeto no llega a cero porque dejamos una referencia colgada, el recolector no nos salvará.

Por otro lado, cuando hablamos de aplicaciones .NET que corren en Windows, dichas aplicaciones suelen consumir diversos recursos del SO, que idealmente deben ser liberados apenas dejan de ser usados.

El autor del artículo menciona una técnica "ninja" para eliminar pérdidas:

The ninja way :)

Aunque él prefiere usar herramientas de más alto nivel, como las mencionadas aquí:

Herramientas Copantes

Causas usuales de memory leaks en .NET:
  1. Referencias estáticas (atributos estáticos y Singletons). Además, un objeto estático no liberado que contiene otros objetos hace que todos ellos no sean liberados...
  2. Eventos (o eventos estáticos) que no cancelan su subscripción
  3. No invocar al método Dispose
  4. Método Dispose (de una clase propia) incompleto
  5. Bugs en las bibliotecas que usa el proyecto o en .NET (sólo considerar esto una vez que nos hayamos cerciorado de que nuestro código está limpio)
Luego de mostrar varios ejemplos de leaks y su detección usando la herramienta dotTrace, el autor menciona algunas prácticas para prevenir leaks:
  1. Todo objeto que crea un objeto es responsable por destruirlo, a menos que hablemos del patrón Factory. En ese caso, se puede responsabilizar al cliente de la factory, o agregar a ésta la funcionalidad de destruir los objetos que creó (pasándole un id, por ejemplo)
  2. Los eventos son la principal causa de leaks en .NET. Siempre dar de baja las subscripciones cuando dejen de ser necesarias
  3. Siempre invocar a Dispose, y mantener actualizados los Dispose de nuestras clases cuando agregamos recursos a ellas

Finalmente, el autor recomienda una serie de herramientas muy interesantes. Aconsejo verlas en el artículo original.

Comments

Post a Comment

Popular posts from this blog

Upgrading Lodash from 3.x to 4.x

Spanish version / Versión en Español There are many breaking changes from version 3.x to 4.x; all changes are detailed in the Lodash changelog . There is also a list of deprecated functions , with a regex you can use to detect usages in your code. However, since it is not an exhaustive list, I will list the changes I encountered when performing my own migration, to help anyone undergoing the same process. Direct renames This section includes functions in which only the name changed, i.e. the arguments and return value are the same. 3.x 4.x contains includes first head rest tail invoke invokeMap padLeft padStart padRight padEnd Direct renames if not using thisArg This section includes functions in which the only change is dropping "thisArg". If you are not using it, you can just rename. If you are using thisArg in 3.x, it can be dropped if you are using iteratee to acce...
Keep reading

C++/CLI: Trigger events from C++ native code and handle them in Managed code, Part I

Spanish version / Versión en Español Imagine we want to trigger an event from a native class which has a C++/CLI wrapper as an interface to managed code (C#, VB.NET). And let's deal with the general case in which we desire to pass extra information along with the event, and said information is not inside a CLR basic type, that is one which both native and managed C++ understand (int, float, char, and so on). In the native class, declare, just for convenience, a pointer to function type: typedef <nativeReturnType> ( __stdcall * PFOnEventCallback )( <nativeParameters> ); Still in the native class, declare a field of the type declared in 1): PFOnEventCallback m_fireEvent; In the place in the native class where we want to trigger the event: if( m_fireEvent ) m_fireEvent( <nativeParameters> ); (This suggests you to initialize m_fireEvent to 0, or NULL if you prefer) Now we need a setter for m_...
Keep reading

Traduciendo un custom control de Windows Forms de VB.NET a C#

Versión en inglés / English version No es tan fácil como tirar el código en un traductor , copiar y pegar. Hay ciertos detalles a tener en cuenta, a saber: Una vez creado el nuevo proyecto C#, en vez de crear el .cs y el .Designer.cs a mano, es mejor hacer click derecho al proyecto->Add->User Control. De esta forma, el .cs y el .Designer.cs ya quedan vinculados. Antes de largarse a editar el .cs y el .Designer.cs, abrir el control en vista diseño. Abrir la ventana de Toolbox, agregar un control cualquiera (un Label, por ejemplo) y salvar. Esto generará el .resx del control. Hecho eso, se puede eliminar el control que habíamos agregado. Si el proyecto original usa recursos, o sea que también hay un .resx a nivel proyecto, hay que generar uno. Esto se hace yendo a las propiedades del proyecto, sección Resources. Lo único que veremos será un link que dirá "This project does not contain a default resources file. Click here to create one.". Click allí y listo....
Keep reading