为什么创建 appdomain 如此昂贵？答案

【问题标题】：Why is creating an appdomain so expensive?为什么创建 appdomain 如此昂贵？
【发布时间】：2010-10-12 16:32:10
【问题描述】：

创建应用程序域如此昂贵的确切原因是什么。它们共享相同的堆、相同的程序集等。消耗如此多资源的 CLR 究竟需要做什么？

我们已经看到从另一个 appdomain 访问类型/实例需要 10 秒的场景 （更新：两个 appdomains 将使用的所有必需程序集都已加载到生成新 appdomain 的当前 appdmomain , 除了一个）。有趣的是，这只发生在第一次访问时。所有后续访问都非常快。

更新2：

我们附上了 VS 2010 采样分析器，结果如下：

做大部分个人工作的功能： System.AddIn.Pipeline.FrameworkElementAdapters.ViewToContractAdapter（类 System.Windows.FrameworkElement) 独家样品 %43,02

（是的，我们在这里使用 WPF 插件 API）

【问题讨论】：

【解决方案1】：

需要为 appdomain 初始化大量的管道。特别是因为它们不共享相同的堆或相同的程序集集。您的问题中有一个错误的细节。它们的价值在于仍然比创建新流程的成本低很多。

在看到编辑后：10 秒相当长，并且除了 appdomain 对需要加载的程序集进行冷启动之外，不容易解释。磁盘或网络开销。

【讨论】：

这正是我感兴趣的“大量管道”。
托管堆是每个进程所有 AppDomain 都共享同一个托管堆。
如果你真的想知道那么你可以通过研究SSCLI20源代码。公平警告：appdomain 和 fusion 相关的代码密密麻麻，而且数量很多。
不，将堆分开是应用程序域的全部意义所在。
查看 AppDomainSetup.LoaderOptimization 属性的文档。但您通常会使用 appdomain 来运行 不同的 代码。一些 SQL/CLR 查询，一个 ASP.NET 网页请求，一个插件。

【解决方案2】：

这不是对问题的完整解释，而是有用的提示：

使用这些优化，以下方法：

FrameworkElementAdapters.ViewToContractAdapter
FrameworkElementAdapters.ContractToViewAdapter

工作速度更快。

【讨论】：