Véase también estos recursos relacionados:¿Puede un compilador de C# conforme optimizar una variable local (pero no utilizada) si es la única referencia fuerte a un objeto?
- Does the .NET garbage collector perform predictive analysis of code? (desbordamiento de pila)
- WP7: When does GC Consider a Local Variable as Garbage (artículo de blog en MSDN)
En otras palabras:
Puede un objeto referenciado por una variable local ser reclamadas antes de la variable sale del ámbito (por ejemplo. porque la variable está asignada, pero no se volvió a utilizar), o ¿ese objeto está garantizado para ser inelegible para la recolección de basura hasta que la variable salga del alcance?
Me explico:
void Case_1()
{
var weakRef = new WeakReference(new object());
GC.Collect(); // <-- doesn't have to be an explicit call; just assume that
// garbage collection would occur at this point.
if (weakRef.IsAlive) ...
}
En este ejemplo de código, que, obviamente, tengo que planificar la posibilidad de que el new'ed object
sea reclamado por el recolector de basura; por lo tanto, la declaración if
.
(Tenga en cuenta que estoy usando weakRef
con el único propósito de comprobar si el new'ed object
es todavía alrededor.)
void Case_2()
{
var unusedLocalVar = new object();
var weakRef = new WeakReference(unusedLocalVar);
GC.Collect(); // <-- doesn't have to be an explicit call; just assume that
// garbage collection would occur at this point.
Debug.Assert(weakRef.IsAlive);
}
El principal cambio en este ejemplo de código de la anterior es que el new'ed object
está fuertemente referenciado por una variable local (unusedLocalVar
). Sin embargo, esta variable nunca se usa nuevamente después de que se haya creado la referencia débil (weakRef
).
Pregunta: es un conformando compilador de C# permite optimizar las dos primeras líneas de Case_2
en los de Case_1
si se ve que unusedLocalVar
sólo se utiliza en un solo lugar, es decir, como un argumento a la WeakReference
constructor? es decir, ¿hay alguna posibilidad de que la afirmación en Case_2
pueda fallar alguna vez?
También tenga en cuenta que, en las versiones de depuración, la variable se mantiene explícitamente viva hasta el final del alcance para que el depurador pueda verla; solo en las compilaciones de lanzamiento verá este comportamiento. –
@Andy - punto interesante. No es que importe, pero supongo que este comportamiento está gobernado por JITter. –
Y, para completar, es por eso que configurar 'unusedLocalVar = null' en el _end_ del método suele ser una desoptimización. –