Java和C#根据需要初始化静态数据的原因是什么？

Question

我现在正在阅读“Go编程语言”，我已经阅读了包初始化一章，它告诉(或者我看错了) Go使用了急切的初始化。

因此，随着时间的推移，我们看到了C++急切地初始化，然后是Java初始化，C#也是按需初始化，然后返回到急切的初始化(这些语言不是严格相关的，我说的是时间)。

我很好奇(从历史的角度来看)为什么选择随需应变模型用于Java和C#。

Answer 1

C++和Go被设计成编译成本机代码。两者在构建过程中都有一个阶段，其中单独的模块被连接在一起，以产生一个单一的组合模块。一旦完成，所有可用对象的完整列表就可用了。因此，初始化任何需要初始化的对象的最简单方法是扫描列表，检查init代码，并调用它(可能比这稍微微妙一些，但作为一个广义的概念层次，它已经足够接近于讨论的目的)。

Java和C#都是设计用来在虚拟机环境中运行的。Java专为执行按需加载代码而设计的.链接被推迟到运行时，以便允许模块驻留在远程服务器上，在远程服务器上它们可以在不更改其余程序的情况下进行更新(这对于Java最初的设计目的非常重要，因为Java最初的设计目的是为智能电视系统编写应用程序)。此外，可以在运行时(使用Class.forName)将类添加到系统中。这意味着Java应用程序不可能在构建时，甚至在应用程序开始运行时，确定它可能使用的所有类的完整列表。因此，Java不可能在应用程序启动时执行初始化。

C#，AFAIK，有一个设计目标，它需要能够用于任何已经可以使用Java的应用程序。因此，它需要遵循Java在使用随需加载方面的领先地位，尽管它确实有一个单独的链接步骤，因为如果不这样做，就很难支持网络加载的应用程序。

Answer 2

我关于为什么延迟初始化在.NET中可能更可取的想法：

1. 对于debug来说，急切的init可能是相当困难的，我现在还不知道，但是更早的时候，当我在C++中遇到静态init的问题时，这是一场噩梦，我宁愿放弃在一些cases.静态init依赖项中使用static，即使在C#中也可能是一个头疼的问题，幸运的是，它们更容易调试，而且测试的可能性也很有限。有关进一步信息，请参见乔恩·斯基特的这篇文章。
2. 避免不必要的init与C++常量不同，.NET常量不太强大，因此static看到了非常广泛的用法。有了大量静态初始化的内存，根据需要初始化它可能会更明智，而不是进一步延长程序启动时间--这对于JIT编译的language.来说已经是一件痛苦的事--这与.NET对.dlls的独占使用和它们在程序运行时的动态加载类似。