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

VB.NET: Raise base class events from a derived class

Spanish version / Versión en Español Say we: Have a class we want to divide into subclasses The future base class has events The refactoring leads us to the need of raising an event declared in the base class, from a derived class. When we try to do point 3, we will get a compile error saying that a derived class cannot raise events from a base class. To get around this, we add a protected method in the base class which encapsulates the RaiseEvent call, and call that method from the derived class using MyBase. This way: In the base class (parameters as needed): Protected Overridable Sub OnMessageGenerated(ByVal NewSender As Object, ByVal NewMessage As String) RaiseEvent MessageGenerated(NewSender, New MessageEventArgs(NewMessage)) End Sub And in the derived class: 'Do stuff 'Raise base class event MyBase.OnMessageGenerated( Me, "Message" ) 'Do more stuff... References: Mark Gilbert post
Keep reading

Apache Kafka - I - High level architecture and concepts

Image
Spanish version / Versión en Español First of all, what is Apache Kafka ? An initial definition for it is "a high-throughput distributed messaging system". Breaking this down a bit: High throughput: One of the main goals of Kafka is to process as much messages per unit of time as possible, in a scalable and fault-tolerant way. For example, LinkedIn , which is where Kafka originated, needs to achieve throughputs in the order of 20 million messages per second and 3 GB of data per second. Distributed messaging system: In a generic distributed system , networked computers work together for a common goal. In Kafka's case, that goal is to send data from points A 1 , A 2 , ... A N , to B 1 , B 2 , ... B M . A common benefit of this kind of system, which is crucial to Kafka's success, is horizontal scalability : the ability to handle higher and higher volumes of data by adding nodes to the system (not to be confused with  vertical scalability , whic
Keep reading

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