.net - seguridad - residuos solidos
Recolección de basura: ¿es necesario establecer objetos grandes para anular en un método de eliminación? (6)
¿Es necesario establecer objetos grandes para null cuando se implementa un método Dispose() ?
¿Qué quieres decir con "objeto grande"?
Sin embargo, al menos debería llamar a Dispose () en cualquier miembro que implemente IDisposable.
El propósito de un método de disposición es liberar todos los recursos asociados con su clase, y la clase de los padres llamando al método de disposición de clase base. Lea este enlace, debería aclarar un poco las cosas:
No Usualmente.
El recolector de elementos no utilizados busca objetos rooteados y las dependencias circulares no impiden la recopilación si ninguno de los objetos está rooteado.
Hay una advertencia: si el objeto A tiene una referencia al objeto B, y el objeto B está siendo eliminado, es posible que desee limpiar esa relación o de lo contrario podría terminar con una fuga. El lugar más común de esta superficie está en los manejadores de eventos (la referencia de A-> B es aquella que B controla, porque se suscribió a un evento en A). En este caso, si A todavía está rooteado, B no se puede recolectar aunque se haya eliminado.
No es necesario, como han señalado otros, pero es una buena práctica y ayuda con la depuración.
Una vez que un objeto ha terminado con un puntero que está usando, establecerlo en nulo ayuda a prevenir la reutilización de ese objeto más adelante (obtendrá una excepción de referencia nula).
La misma lógica se aplica a la configuración de punteros de miembro para anular en destructores de C ++ una vez que los haya eliminado. No es necesario hacerlo, pero ayuda con la solución de problemas más adelante.
Piensa un poco en el propósito de los métodos desechables: generalmente es porque tienes algún recurso que no se liberará durante la recolección de basura. Esto suele ser algo así como una conexión de base de datos o un manejador de archivo. Por lo tanto, una vez que se ha llamado al método Dispose, todos esos recursos se han liberado.
Yo diría que tener nulos flotando es más dañino que tener objetos "zombies" flotando alrededor.
Si una clase tiene un método de eliminación, la mejor práctica es llamarlo. la razón detrás de esto es que Dispose se ejecuta cuando se llama, mientras que al establecer el objeto como nulo simplemente se agrega una entrada a la cola de Finalizar en GC, y no podemos determinar cuándo se ejecutará GC.
No hay beneficio en el rendimiento al implementar el método Dispose en tipos que usan solo recursos administrados (como matrices) porque el recolector de basura los reclama automáticamente. Utilice el método Dispose principalmente en objetos administrados que usan recursos nativos y en objetos COM que están expuestos a .NET Framework. Los objetos administrados que usan recursos nativos (como la clase FileStream) implementan la interfaz IDisposable.
Un medio elegante de invocar Dispose que han adoptado es usar el constructo "using". Para aquellos de ustedes que pueden no estar familiarizados con el constructo, proporcionan un medio para que implicity invoque a Dispose () en una instancia que implementa IDisposable incluso si se lanza una excepción durante la operación. El siguiente es un ejemplo de la construcción que usa:
using(DisposableClass dc = new DisposableClass())
{
dc.PerformActionOnUmanagedResources();
dc.PerformAnotherActionOnUmanagedResources();
}
En el ejemplo anterior, si se lanzaba una excepción en el método PerformActionOnUmanagedResources (), aunque el método PerformAnotherActionOnUmanagedResources () no se procesara, el bloque que lo usa aún invocará implicitamente el método Dispose en dc, garantizando el valor real de cualquier recurso no administrado.