测试/验证弱引用

Question

我想验证设置WeakReference 的代码不会意外持有对被引用对象的强引用。 （这里是 an example 说明如何很容易意外地做到这一点。）

这看起来是检查无意强引用的最佳方法吗？

TestObject testObj = new TestObject();
WeakReference wr = new WeakReference(testObj);

// Verify that the WeakReference actually points to the intended object instance.
Assert.Equals(wr.Target, testObject);

// Force disposal of testObj;
testObj = null;
GC.Collect();
// If no strong references are left to the wr.Target, wr.IsAlive will return false.
Assert.False(wr.IsAlive);

Answer 1

我就此与 Microsoft 取得了联系，并了解到/确认：

• GC.Collect() 强制进行阻塞式垃圾回收。
• 当GC.Collect() 运行时，它不会神秘地跳过符合收集条件的对象。遵循可预测的规则来确定要收集哪些对象。只要您了解这些规则（即如何处理可终结对象），就可以强制销毁特定对象，尽管被销毁对象使用的内存可能会或可能不会被释放。

更多信息见我的博客：Can .Net garbage collection be forced?

Answer 2

涉及WeakReference 对象的单元测试比您想象的要复杂。正如您和其他人所指出的，GC.Collect() 可能会“强制”进行垃圾回收，但这仍然取决于您的对象没有对其的引用。

不幸的是，如何构建代码可能会改变对象是否仍然具有对它们的引用。更具体地说，无论您是在 Debug 还是 Release 模式下构建，都可以并且将在对象仍然植根时发生变化（更准确地说，取决于您是否打开了优化；Debug 默认关闭它们，而 Release 默认打开它们） .调试模式关闭了很多优化，它甚至倾向于根目录在当前正在执行的方法中创建/声明的对象。因此，您的单元测试可能在 Debug 构建中失败，但在 Release 构建中成功。

在您的示例中，即使您将 testObj 设置为 NULL，编译器仍试图通过保持其先前值的根来在 Debug 构建中提供帮助。这意味着无论您调用多少次GC.Collect()，wr.IsAlive 将始终返回 TRUE。

那么，你怎么能测试WeakReferences？很简单：在另一种方法中创建它们以及它们所基于的对象。只要该方法没有内联，而且在大多数情况下不会内联，编译器就不会根您关心的对象，并且您可以让您的测试在调试和发布版本中都通过。

下面的函数为您提供了如何执行此操作的提示：

public static Tuple<WeakReference, ManualResetEvent, int> GetKillableWr(Func<object> func, bool useGetHashCode = false)
{
    var foo = func();
    var result = new Tuple<WeakReference, ManualResetEvent, int>(new WeakReference(foo), new ManualResetEvent(false), useGetHashCode ? (foo?.GetHashCode() ?? 0) : RuntimeHelpers.GetHashCode(foo));

    Task.Factory.StartNew(() =>
    {
        result.Item2.WaitOne();
        GC.KeepAlive(foo);  // need this here to make sure it doesn't get GC-ed ahead of time
        foo = null;
    });

    return result;
}

使用这个，只要你在func参数在内创建你的对象，你就可以为你选择的对象创建一个WeakReference在您发出返回的ManualResetEvent 并调用GC.Collect() 后，就不会被root。正如其他人所指出的，调用以下代码以确保在需要时进行清理会很有帮助...

GC.Collect();
GC.WaitForPendingFinalizers();
GC.Collect();

编辑：

还有一些其他的“陷阱”需要担心。一个常见的涉及Strings。 String 文字和常量总是有根的，因为它们被编译为您的 DLL/EXE 的引用。因此，new WeakReference("foo") 之类的东西将始终显示为活动的，因为“foo”已存储到您的 DLL 中，并且在编译代码中提供了对该存储文字的引用。解决此问题的一种简单方法是使用 new StringBuilder("<your string here>").ToString() 而不是字符串文字。

再次编辑：

另一个“陷阱”是在 Release 构建中，优化会导致 GC 更加激进，与上述情况不同，这可能会导致对象比您预期的更快超出范围。在下面的代码中，wr.IsAlive 有时会返回 FALSE，因为 GC 检测到 myObject 不会被方法中的其他任何东西使用，因此它可以进行垃圾回收。解决此问题的方法是将GC.KeepAlive(myObject) 放在方法的末尾。这将使myObject 保持扎根，直到至少执行该行。

public static void SomeTest()
{
    var myObject = new object();
    var wr = new WeakReference(myObject);
    GC.Collect();
    Assert.True(wr.IsAlive, "This could fail in Release Mode!");
}

Answer 3

我昨天才这样做。这是我必须添加的内容，以确保集合发生在您上次断言之前：

        GC.Collect();
        GC.WaitForPendingFinalizers();
        GC.WaitForFullGCComplete();
        GC.Collect();

如果在此之后 .IsAlive 仍然为真，则很可能某处仍有强引用。

顺便说一句 - 当您访问 WeakReference 目标时，请务必不要检查 .IsAlive。要避免检查 .IsAlive 和 .Target 之间的竞争条件，请执行以下操作：

var r = weakRef.Target AS Something;
if (r != null)
{
    ... do your thing
}