Establecer objetos en Nulo/Nada después de su uso en .NET
¿Deberías configurar todos los objetos en null( Nothingen VB.NET) una vez que hayas terminado con ellos?
Entiendo que en .NET es esencial deshacerse de cualquier instancia de objetos que implementen la IDisposableinterfaz para liberar algunos recursos, aunque el objeto aún puede ser algo después de eliminarse (de ahí la isDisposedpropiedad en los formularios), por lo que supongo que aún puede residir. en la memoria o al menos en parte?
También sé que cuando un objeto sale del alcance, se marca para su recolección y está listo para el siguiente paso del recolector de basura (aunque esto puede llevar tiempo).
Entonces, con esto en mente, ¿se configurará para nullacelerar el sistema que libera la memoria, ya que no tiene que darse cuenta de que ya no está dentro del alcance y hay algún efecto secundario negativo?
Los artículos de MSDN nunca hacen esto en ejemplos y actualmente lo hago porque no veo el daño. Sin embargo me he encontrado con una mezcla de opiniones por lo que cualquier comentario es útil.
Karl tiene toda la razón: no es necesario establecer los objetos como nulos después de su uso. Si un objeto implementa IDisposable, solo asegúrese de llamar IDisposable.Dispose()cuando haya terminado con ese objeto (envuelto en un try.. finallyo un using()bloque). Pero incluso si no recuerdas llamar Dispose(), el método finalizador del objeto debería llamar Dispose()por ti.
Pensé que este era un buen tratamiento:
Profundizando en IDisposable
y esto
Entendiendo IDisposable
No tiene ningún sentido tratar de adivinar el GC y sus estrategias de gestión porque es opaco y autoajustable. Hubo una buena discusión sobre el funcionamiento interno con Jeffrey Richter en Dot Net Rocks aquí: Jeffrey Richter sobre el modelo de memoria de Windows y el libro CLR de Richter a través de C#, capítulo 20, tiene un excelente tratamiento:
Otra razón para evitar establecer objetos como nulos cuando haya terminado con ellos es que, de hecho, puede mantenerlos vivos por más tiempo.
p.ej
void foo()
{
var someType = new SomeType();
someType.DoSomething();
// someType is now eligible for garbage collection
// ... rest of method not using 'someType' ...
}
permitirá que el objeto referido por algún tipo sea GC después de la llamada a "DoSomething", pero
void foo()
{
var someType = new SomeType();
someType.DoSomething();
// someType is NOT eligible for garbage collection yet
// because that variable is used at the end of the method
// ... rest of method not using 'someType' ...
someType = null;
}
A veces puede mantener vivo el objeto hasta el final del método. El JIT generalmente optimizará la asignación a null , por lo que ambos bits de código terminan siendo iguales.
No, no anules los objetos. Puede consultar https://web.archive.org/web/20160325050833/http://codebetter.com/karlseguin/2008/04/28/foundations-of-programming-pt-7-back-to-basics- memoria/ para obtener más información, pero configurar las cosas en nulo no hará nada, excepto ensuciar su código.
También:
using(SomeObject object = new SomeObject())
{
// do stuff with the object
}
// the object will be disposed of
En general, no es necesario anular los objetos después de su uso, pero en algunos casos creo que es una buena práctica.
Si un objeto implementa IDisposable y se almacena en un campo, creo que es bueno anularlo, sólo para evitar el uso del objeto desechado. Los errores del siguiente tipo pueden resultar dolorosos:
this.myField.Dispose();
// ... at some later time
this.myField.DoSomething();
Es bueno anular el campo después de desecharlo y obtener un NullPtrEx justo en la línea donde se usa el campo nuevamente. De lo contrario, es posible que se encuentre con algún error críptico en el futuro (dependiendo exactamente de lo que haga DoSomething).
