为什么委托是引用类型？

Question

关于已接受答案的快速说明：我不同意Jeffrey's answer 的一小部分，即由于Delegate 必须是引用类型，因此所有代表都是引用类型。 （多级继承链排除值类型是不正确的；例如，所有枚举类型都继承自 System.Enum，而 System.ValueType 又继承自 System.ValueType，后者继承自 System.Object，all 引用类型。）但是我认为，从根本上说，所有委托实际上不仅继承自 Delegate，而且继承自 MulticastDelegate，这是这里的关键实现。正如Raymond points out 在对他的 答案的评论中，一旦你承诺支持多个订阅者，不 对委托本身使用引用类型真的没有意义，考虑到某个地方需要一个数组。

---

见底部更新。

如果我这样做，我总是觉得奇怪：

Action foo = obj.Foo;

我每次都在创建一个新 Action 对象。我确信成本是最低的，但它涉及分配内存以供以后进行垃圾收集。

鉴于委托本身自身是不可变的，我想知道为什么它们不能是值类型？那么像上面这样的一行代码只会对堆栈上的内存地址进行简单的分配*。

即使考虑匿名函数，这似乎（对我）也可以。考虑以下简单示例。

Action foo = () => { obj.Foo(); };

在这种情况下foo 确实构成了一个闭包，是的。在很多情况下，我想这确实需要一个实际的引用类型（例如当局部变量被关闭并在闭包中被修改时）。 但在某些情况下，它不应该。例如在上面的例子中，支持闭包的类型看起来像这样： 我收回我原来的观点。下面确实需要是一个引用类型（或者：它不需要，但如果它是struct，它无论如何都会被装箱）。所以，忽略下面的代码示例。我只留下它来为特别提到它的答案提供上下文。

struct CompilerGenerated
{
    Obj obj;

    public CompilerGenerated(Obj obj)
    {
        this.obj = obj;
    }

    public void CallFoo()
    {
        obj.Foo();
    }
}

// ...elsewhere...

// This would not require any long-term memory allocation
// if Action were a value type, since CompilerGenerated
// is also a value type.
Action foo = new CompilerGenerated(obj).CallFoo;

这个问题有意义吗？在我看来，有两种可能的解释：

• 将委托正确地实现为值类型需要额外的工作/复杂性，因为支持诸如 确实修改局部变量值的闭包之类的东西无论如何都需要编译器生成的引用类型。
• 还有一些其他原因，说明在底层，委托不能被实现为值类型。

最后，我并没有为此失眠；这只是我一直好奇的事情。

---

更新：为了回应 Ani 的评论，我明白了为什么上面示例中的 CompilerGenerated 类型也可能是引用类型，因为如果委托将包含一个函数指针和一个对象指针它无论如何都需要一个引用类型（至少对于使用闭包的匿名函数，因为即使你引入了一个额外的泛型类型参数——例如，Action<TCaller>——这也不会涵盖无法命名的类型！ ）。 然而，这一切都让我后悔将编译器生成的闭包类型问题带入讨论！我的主要问题是关于 delegates，即 with 函数指针和对象指针的东西。在我看来， 仍然可能是一种值类型。

也就是说，即使这样……

Action foo = () => { obj.Foo(); };

...需要创建一个引用类型的对象（支持闭包，并给delegate一些引用），为什么需要创建两个（支持闭包的对象加上Action委托）？

_{*是的，是的，实现细节，我知道！我真正的意思是短期记忆存储。}

Answer 1

问题归结为：CLI（公共语言基础结构）规范说委托是引用类型。为什么会这样？

一个原因在今天的 .NET Framework 中显而易见。在最初的设计中，有两种委托：普通委托和“多播”委托，它们的调用列表中可以有多个目标。 MulticastDelegate 类继承自 Delegate。由于不能从值类型继承，Delegate 必须是引用类型。

最后，所有实际的委托最终都成为了多播委托，但在这个过程的那个阶段，合并这两个类已经太晚了。看到这个blog post关于这个确切的主题：

我们放弃了 Delegate 和 MulticastDelegate 之间的区别 在V1结束时。那时，它会是一个巨大的 更改为合并两个类，所以我们没有这样做。你应该 假装它们被合并并且只存在 MulticastDelegate。

此外，委托目前有 4-6 个字段，都是指针。 16 字节通常被认为是节省内存仍然胜过额外复制的上限。一个 64 位的MulticastDelegate 占用 48 个字节。鉴于此，他们使用继承的事实表明类是自然的选择。

Answer 2

Delegate 需要成为一个类只有一个原因，但它是一个很大的原因：虽然委托可以足够小以允许作为值类型进行高效存储（在 32 位系统上为 8 个字节，在 32 位系统上为 16 个字节） 64 位系统），它不可能小到足以有效保证如果一个线程尝试写入委托而另一个线程尝试执行它，则后一个线程最终不会在新目标上调用旧方法，或旧目标上的新方法。允许这样的事情发生将是一个重大的安全漏洞。让委托成为引用类型可以避免这种风险。

实际上，比让委托成为结构类型更好的是让它们成为接口。创建闭包需要创建两个堆对象：一个编译器生成的对象来保存任何封闭的变量，一个委托来调用该对象的正确方法。如果委托是接口，则持有封闭变量的对象本身可以用作委托，而无需其他对象。

Answer 3

想象一下，如果委托是值类型。

public delegate void Notify();

void SignalTwice(Notify notify) { notify(); notify(); }

int counter = 0;
Notify handler = () => { counter++; }
SignalTwice(handler);
System.Console.WriteLine(counter); // what should this print?

根据您的建议，这将在内部转换为

struct CompilerGenerated
{
    int counter = 0;
    public Execute() { ++counter; }
};

Notify handler = new CompilerGenerated();
SignalTwice(handler);
System.Console.WriteLine(counter); // what should this print?

如果delegate 是一个值类型，那么SignalEvent 将获得handler 的副本，这意味着将创建一个全新的CompilerGenerated（handler 的副本）并传递给@987654328 @。 SignalTwice 将执行委托两次，这会将副本中的counter 增加两次。然后SignalTwice返回，函数打印0，因为原来没有修改。

Answer 4

这是一个不知情的猜测：

如果委托被实现为值类型，则复制实例的成本会非常高，因为委托实例相对较重。也许 MS 认为将它们设计为不可变的 reference 类型会更安全——将机器字大小的引用复制到实例相对便宜。

委托实例至少需要：

• 对象引用（包装方法的“this”引用，如果它是实例方法）。
• 指向包装函数的指针。
• 对包含多播调用列表的对象的引用。请注意，根据设计，委托类型应支持使用相同委托类型的多播。

让我们假设值类型委托以与当前引用类型实现类似的方式实现（这可能有点不合理；很可能选择了不同的设计来减小大小）来说明。使用 Reflector，以下是委托实例中所需的字段：

System.Delegate: _methodBase, _methodPtr, _methodPtrAux, _target
System.MulticastDelegate: _invocationCount, _invocationList

如果实现为结构（无对象标头），这些将在 x86 上增加 24 个字节，在 x64 上增加 48 个字节，这对于结构来说是巨大的。

---

另一方面，我想问一下，在您提议的设计中，将 CompilerGenerated 闭包类型设为结构有何帮助。创建的委托的对象指针指向哪里？在没有适当的逃逸分析的情况下将闭包类型实例留在堆栈上将是非常冒险的事情。

Answer 5

我可以说，将委托作为引用类型绝对是一个糟糕的设计选择。它们可以是值类型，并且仍然支持多播委托。

想象一下，Delegate 是一个由以下组成的结构体，比方说： 对象目标； 指向方法的指针

它可以是一个结构，对吧？ 只有当目标是一个结构体时才会发生装箱（但委托本身不会被装箱）。

您可能认为它不支持 MultiCastDelegate，但我们可以： 创建一个新对象，该对象将保存普通委托数组。 将一个 Delegate（作为结构体）返回给该新对象，该对象将实现 Invoke 迭代其所有值并在它们上调用 Invoke。

因此，对于永远不会调用两个或更多处理程序的普通委托，它可以作为结构工作。 不幸的是，这在 .Net 中不会改变。

---

附带说明，方差不要求 Delegate 是引用类型。委托的参数应该是引用类型。毕竟，如果你传递一个字符串是需要一个对象（用于输入，而不是 ref 或 out），那么就不需要强制转换，因为字符串已经是一个对象。

Answer 6

我在网上看到了这段有趣的对话：

不可变并不意味着它必须是值类型。还有一些东西 是值类型不需要是不可变的。两人经常去 手拉手，但它们实际上不是一回事，而且有 实际上是 .NET Framework 中每个的反例（字符串 类，例如）。

答案是：

不同之处在于，虽然不可变引用类型是 相当普遍且完全合理，使值类型可变 几乎总是是个坏主意，并且可能会导致一些非常混乱 行为！

取自here

因此，在我看来，这个决定是由语言可用性方面做出的，而不是编译器技术上的困难。我喜欢可为空的代表。

Answer 7

我想一个原因是支持多转换委托 多转换委托比简单地指示目标和方法的几个字段更复杂。

只有在这种形式下才有可能的另一件事是委托方差。这种差异需要两种类型之间的引用转换。

有趣的是，F# 定义了它自己的函数指针类型，它类似于委托，但更轻量级。但我不确定它是值类型还是引用类型。