问静态构造函数会导致性能开销吗？

EN

我认为“大量”在大多数用例中都被夸大了。

具有静态构造函数(即使它什么也不做)会由于beforefieldinit flag的存在/不存在而影响类型初始化时间。当你有一个静态构造函数时，有更严格的计时保证。

对于大多数代码，我建议这并没有太大的不同--但是如果你是紧循环并且访问一个类的静态成员，它可能会。就我个人而言，我不会太担心这一点--如果你怀疑它与你的实际应用程序相关，那么测试它而不是猜测。在这里，微基准很可能会夸大效果。

值得注意的是，当涉及到类型初始化时，.NET 4 behaves somewhat differently to previous versions -因此任何基准测试都应该真正显示不同的版本，以便具有相关性。

我刚刚复制了他的测试结果。

对于调试版本的1000000000次迭代，我得到：

带有static constructor

• 3.6s的静态类的
• 4s带有注释掉的static constructor
• 2.9s的相同类，带有带有static构造函数的非静态类(并在迭代之前创建实例)，或者是静态构造函数，或者不是

与发布的 build相同，但也会突出不同之处：

带静态构造函数的

• 静态类: 4046.875ms不带静态构造函数的
• 静态类:带静态构造函数的484.375ms
• Instance :不带静态构造函数的484.375ms
• Instance : 484.375ms

CLR为静态构造函数的执行提供了非常强大的保证，它承诺在类中的任何方法可以运行之前只调用它们一次。当有多个线程使用该类时，这种保证很难实现。

浏览一下SSCLI20的CLR源代码，我发现有相当多的代码专门用于提供这种保证。它维护一个由全局锁保护的运行静态构造函数的列表。一旦它在该列表中获得一个条目，它就会切换到特定于类的锁，以确保没有两个线程可以运行构造函数。对指示构造函数已运行的状态位进行双重检查锁定。提供异常保证的大量难以理解的代码。

好吧，这段代码不是免费的。把它加到cctor本身的执行时间上，你就会看到一些开销。像往常一样，不要让这件事影响你的风格，这也是一个你不想给自己提供的非常好的保证。并在修复之前进行测量。