为什么编译器不能通过内联优化闭包变量？

Question

我有一个像这样的Main 方法：

static void Main(string[] args)
{
     var b = new byte[1024 * 1024];

     Func<double> f = () =>
     {
         new Random().NextBytes(b);
         return b.Cast<int>().Average();
     };

     var avg = f();
     Console.WriteLine(avg);
}

由于我在这里访问一个局部变量b，编译器创建一个类来捕获该变量，b 成为该类的字段。然后b 的生命周期与编译器生成的类的生命周期一样长，它会导致内存泄漏。即使b 超出范围（可能不在这种情况下，但想象这是在另一个方法内部而不是Main），字节数组也不会被释放。

我想知道的是，既然在声明 Func 后我没有在任何地方访问或修改 b，为什么编译器不能内联该局部变量而不费心创建一个类？像这样：

Func<double> f = () =>
{
    var b = new byte[1024 * 1024];
    new Random().NextBytes(b);
    return b.Cast<int>().Average();
};

我在 Debug 和 Release 模式下编译了这段代码，DisplayClass 是在这两种模式下生成的：

这只是没有作为优化实现还是我缺少什么？

Answer 1

这只是没有作为优化实现还是我缺少什么？

对于您给出的特定示例，您可能不想进行该代码转换，因为它会改变程序的语义。如果new 抛出异常，则在原始程序中它应该在执行委托之前这样做，并且在您的转换中，副作用被延迟。这是否是应该保留的重要财产是有争议的。 （这样做也会给调试器带来问题；调试器已经必须假装闭包类的元素是包含方法体的局部变量，而这种优化可能会使它进一步复杂化。）

但是，更普遍的观点是密切相关的。如果您知道封闭变量仅用于其值，则可以进行许多优化。

当我在编译器团队时 -- 我于 2012 年离开 -- Neal Gafter 和我考虑实施此类优化，以及一些更复杂的优化，旨在减少昂贵对象的生命周期延长过长的可能性意外地。

旁白：更复杂的场景中最简单的是：我们将两个 lambda 转换为委托；一个存储在一个短暂的变量中，并在一个包含对昂贵对象的引用的局部变量上关闭；一个存储在一个长期存在的变量中，并在一个引用廉价对象的本地变量上关闭。昂贵的对象与长期存在的变量一样长，即使它没有被使用。更一般地，多个闭包可以构建为基于封闭关系的分区；当时我们只基于嵌套对闭包进行分区；同一嵌套级别的闭包是一个闭包。给定的场景很少见，并且有明显的解决方法，但如果它根本不发生就好了。

我们没有这样做，因为在我们实施 Roslyn 期间有更重要的优化和功能，我们不想给已经很长的计划增加风险。

我们可以自信地执行此类优化，因为在 C# 中很容易知道局部变量何时被别名化，因此您可以确定在创建闭包后它是否被写入。

我不知道这些优化是否同时实现了；可能不会。

我也不知道编译器是否对 C# 7 本地函数进行了此类优化，但我怀疑答案是“是”。看看如果你尝试一个本地函数会发生什么！