WeakReference zachowuje się inaczej w .Net Framework i .Net Core
Rozważ następujący kod:
using System;
using System.Collections.Generic;
using System.Runtime.CompilerServices;
#nullable enable
namespace ConsoleApp1
{
class Program
{
static void Main()
{
var list = makeList();
var weakRef = new WeakReference(list[0]);
list[0] = null;
GC.Collect();
GC.WaitForPendingFinalizers();
Console.WriteLine(weakRef.IsAlive);
}
[MethodImpl(MethodImplOptions.NoInlining)]
static List<int[]?> makeList()
{
return new List<int[]?> { new int[2] };
}
}
}
- Ten kod jest drukowany w przypadku wydania lub kompilacji debugowania w .Net Framework 4.8
False. - Ten kod jest drukowany w przypadku wydania lub kompilacji debugowania na platformie .Net Core 3.1
True.
Co powoduje tę różnicę w zachowaniu? (Powoduje to niepowodzenie niektórych naszych testów jednostkowych).
Uwaga: makeList()włączyłem inicjalizację listy i wyłączyłem inlining, aby wersja .Net Core działała tak samo jak wersja .Net Framework, ale bezskutecznie.
[EDYCJA] Jak zauważył Hans, dodanie pętli rozwiązuje problem.
Zostanie wydrukowany następujący kod False:
var list = makeList();
var weakRef = new WeakReference(list[0]);
list[0] = null;
for (int i = 0; i < 1; ++i)
GC.Collect();
Console.WriteLine(weakRef.IsAlive);
Ale to wydrukuje True:
var list = makeList();
var weakRef = new WeakReference(list[0]);
list[0] = null;
GC.Collect();
GC.Collect();
GC.Collect();
GC.Collect();
// Doesn't seem to matter how many GC.Collect() calls you do.
Console.WriteLine(weakRef.IsAlive);
To dostaje się jakieś dziwne rzeczy ... Jitter
Odpowiedzi
Tylko dlatego, że coś jest dozwolone , aby być zbierane, nie oznacza to obowiązek być zbierane jak tylko jest to możliwe. Chociaż język stwierdza, że GC może określić, że zmienna lokalna nigdy nie zostanie ponownie odczytana, a tym samym nie uważa jej za element główny, nie oznacza to, że możesz polegać na zawartości zmiennej lokalnej zbieranej natychmiast po ostatnim jej przeczytaniu .
To nie jest jakaś zmiana między zdefiniowanym zachowaniem w środowisku wykonawczym, jest to niezdefiniowane zachowanie w obu środowiskach wykonawczych, więc różnice między nimi są całkowicie akceptowalne.
Otrzymałem odniesienie do zwolnienia, kiedy usunąłem zmienną listy:
using NUnit.Framework;
using System;
using System.Collections.Generic;
namespace NUnitTestProject1
{
public class Tests
{
[TestCase(2, GCCollectionMode.Forced, true)]
public void TestWeakReferenceWithList(int generation, GCCollectionMode forced, bool blocking)
{
static WeakReference CreateWeakReference()
{
return new WeakReference(new List<int[]> { new int[2] });
}
var x = CreateWeakReference();
Assert.IsTrue(x.IsAlive);
GC.Collect(generation, forced, blocking);
Assert.IsFalse(x.IsAlive);
}
}
}
Następujący przypadek testowy kończy się niepowodzeniem:
using NUnit.Framework;
using System;
using System.Collections.Generic;
namespace NUnitTestProject1
{
public class Tests
{
[TestCase(2, GCCollectionMode.Forced, true)]
public void TestWeakReferenceWithList(int generation, GCCollectionMode forced, bool blocking)
{
static List<int[]> CreateList()
{
return new List<int[]> { new int[2] };
}
WeakReference x;
{
var list = CreateList();
x = new WeakReference(list);
list = null;
}
Assert.IsTrue(x.IsAlive);
GC.Collect(generation, forced, blocking);
Assert.IsFalse(x.IsAlive);
}
}
}
Jeśli spojrzymy na IL, zobaczymy, że null jest przypisane do zmiennej lokalnej 1:
IL_0003: call class [System.Collections]System.Collections.Generic.List`1<int32[]> NUnitTestProject1.Tests::'<TestWeakReferenceWithList>g__CreateList|0_0'()
IL_0008: stloc.1
IL_0009: ldloc.1
IL_000a: newobj instance void [System.Runtime]System.WeakReference::.ctor(object)
IL_000f: stloc.0
IL_0010: ldnull
IL_0011: stloc.1
IL_0012: nop