c# - MVVM light Messenger 中的 Action 、局部变量和垃圾收集的奇怪行为

Question

我在使用 MVVM Light 中的 Messenger 系统时遇到了一个非常奇怪的问题。这很难解释，所以这里有一个小程序来演示这个问题:

using System;
using GalaSoft.MvvmLight.Messaging;

namespace TestApp
{
    class Program
    {
        static void Main(string[] args)
        {
            var prog = new Program();
            var recipient = new object();

            prog.RegisterMessageA(recipient);
            prog.RegisterMessageB(recipient);

            prog.SendMessage("First Message");
            GC.Collect();
            prog.SendMessage("Second Message");
        }

        public void RegisterMessageA(object target)
        {
            Messenger.Default.Register(this, (Message msg) =>
            {
                Console.WriteLine(msg.Name + " recieved by A");
                var x = target;
            });
        }

        public void RegisterMessageB(object target)
        {
            Messenger.Default.Register(this, (Message msg) =>
            {
                Console.WriteLine(msg.Name + " received by B");
            });
        }

        public void SendMessage(string name)
        {
            Messenger.Default.Send(new Message { Name = name });
        }

        class Message
        {
            public string Name { get; set; }
        }
    }
}

如果您运行应用程序，这是控制台输出:

First Message recieved by A
First Message received by B
Second Message received by B

如您所见，收件人 A 从未收到第二条消息。但是，B 和 A 之间的唯一区别是一行:语句 var x = target;。如果删除此行，A 会收到第二条消息。

此外，如果您删除 GC.Collect();，则 A 会收到第二条消息。然而，这只是隐藏了问题，因为在真实程序中，垃圾收集器最终会自动运行。

为什么会这样？我假设以某种方式，如果接收者操作从它包含方法范围引用变量，它将操作的生命周期与该范围联系起来，以便一旦超出范围，它就可以被垃圾收集。我完全不明白为什么会这样。我也不明白为什么不从它们定义的范围引用变量的操作没有这个问题。

谁能解释一下这是怎么回事？

Answer 1

好吧，我现在明白为什么会这样了(无论如何我相信)。我以较短的形式复制了它，不使用 lambda 表达式，然后我将解释为什么 lambda 很重要。

using System;
using GalaSoft.MvvmLight.Messaging;

class Program
{
    static void Main(string[] args)
    {
        Receiver r1 = new Receiver("r1");
        Receiver r2 = new Receiver("r2");
        var recipient = new object();

        Messenger.Default.Register<object>(recipient, r1).ShowMessage;
        Messenger.Default.Register<object>(recipient, r2).ShowMessage;

        GC.Collect();
        Messenger.Default.Send(recipient, null);
        // Uncomment one of these to see the relevant message...
        // GC.KeepAlive(r1);
        // GC.KeepAlive(r2);
    }
}

class Receiver
{
    private string name;

    public Receiver(string name)
    {
        this.name = name;
    }

    public void ShowMessage(object message)
    {
        Console.WriteLine("message received by {0}", name);
    }
}

基本上，信使只保留对消息处理程序的弱引用。 (对于接收者也是如此，但这在这里不是问题。)更具体地说，它似乎对处理程序的目标 对象有一个弱引用。它似乎并不关心委托(delegate)对象本身，但目标很重要。所以在上面的代码中，当你保留一个 Receiver对象还活着，仍然使用将该对象作为目标的委托(delegate)。但是，当允许对目标进行垃圾回收时，不会使用使用该对象的处理程序。

现在让我们看看您的两个处理程序:

public void RegisterMessageA(object target)
{
    Messenger.Default.Register(target, (Message msg) =>
    {
        Console.WriteLine(msg.Name + " received by A");
        var x = target;
    });
}

此 lambda 表达式捕获 target 参数。为了捕获它，编译器生成一个新类 - 所以 RegisterMessageA 是有效的:

public void RegisterMessageA(object target)
{
    GeneratedClass x = new GeneratedClass();
    x.target = target;
    Messenger.Default.Register(x.target, x.Method);
}

private class GeneratedClass
{
    public object target;

    public void Method(Message msg)
    {
        Console.WriteLine(msg.Name + " received by A");
        var x = target;
    }
}

现在，除了让 GeneratedClass 实例保持事件状态的委托(delegate)之外，别无他物。将其与您的第二个处理程序进行比较:

public void RegisterMessageB(object target)
{
    Messenger.Default.Register(target, (Message msg) =>
    {
        Console.WriteLine(msg.Name + " received by B");
    });
}

这里，没有捕获变量，所以编译器生成的代码有点像这样:

public void RegisterMessageB(object target)
{
    Messenger.Default.Register(target, RegisterMessageB_Lambda);
}

private static void RegisterMessageB_Lambda(Message msg)
{
    Console.WriteLine(msg.Name + " received by B");
}

这是一个static 方法，所以根本没有委托(delegate)目标。如果委托(delegate)捕获了 this，它将作为实例方法生成。但重要的一点是不需要生成额外的类......所以没有什么可以被垃圾收集的。

我还没有仔细研究 MvvmLight 是如何做到这一点的——它是否只是得到了对委托(delegate)的弱引用，以及 CLR 是否以某种特殊的方式处理它，或者 MvvmLight 是否是将目标与委托(delegate)本身分开。无论哪种方式，我希望这能解释您所看到的行为。关于如何解决您在真实 代码中看到的任何问题 - 基本上，您需要确保对所需的任何委托(delegate)目标保持强引用。

编辑:好的，看起来现在是由于WeakActionGeneric及其基类 WeakAction .我不知道这种行为是否是预期的行为(作者)，但这是负责的代码:)