了解 Windows 中的 AppDomain
我试图更好地理解 appDomains。据我了解，Windows 在一个进程中运行所有应用程序。每个应用程序都封装在驻留在该进程内的自己的对象中。该对象还保存一些不能共享的全局变量。进程中的所有对象不能相互共享任何数据。根据我的理解，appDomain 是一个位于 Windows 进程中的特殊对象。它所做的只是保留对分配给它的所有程序集的引用。如果有人可以详细说明这一点，或者如果我错了可以纠正我。任何好的资源也可以。
I am trying to better understand appDomains. From my understanding Windows runs all applications in a process. each application is encapsulated in it's own object that resides within this process. This object also holds some global varibles which can not be shared. All objects that are in the process can not share any data with one another. An appDomain from my understanding is a special object that sits in the windows process. and all it does is keep a reference to all assemblies assigned to it. If anyone could elaborate more on that or correct me if I am wrong. Also any good resources will do as well.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
听起来这里发生的事情是您将 AppDomain 的概念与.Net 中的实现混淆了。
我们先从概念开始。您可以从概念上将其视为与线程或进程相同的事物。进程的启动相当昂贵，但在各个进程拥有的内存之间提供高度的保护/隔离。线程的启动成本相当低，但针对跨线程内存访问的保护较少。 AppDomain 本质上为线程带来了一些进程级保护。
你可以用这个概念做一些有趣的事情。例如，进程不限于单个 AppDomain，因此您可以让多个应用程序共享一个进程，并且仍然相当确定两个应用程序都不会干扰另一个应用程序或使另一个应用程序崩溃。但主要原因与实施有关。
被管理的 .Net 语言是使用内存模型设计的，以便管理器可以确保应用程序外部的任何内容都不会不适当地干扰应用程序的内存。它们还设计为使用单独的线程进行垃圾收集，这使我们的应用程序仅作为进程中的一个线程运行。即使您只使用一个线程，您也可以启动更多线程或加载其他程序集。那么，AppDomain 的目的是将您的应用程序（及其内存）封装在进程中。它可以作为一个对象来实现，该对象保留对程序集的引用，但这与概念是分开的。
It sounds like what's happening here is that you are confusing the concept of an AppDomain with the implementation in .Net.
Let's start with the concept first. You can think of it conceptually as the same kind of thing as a thread or a process. Processes are fairly expensive to start up, but provide a high degree of protection/separation between the memory owned by individual processes. Threads are fairly cheap to start up, but there is less protection against cross-thread memory access. An AppDomain essentially brings some of the process-level protections to threads.
You can do some interesting things with this concept. For example, processes are not restricted to a single AppDomain, and so you could have multiple apps sharing one process and still be fairly sure that neither app will interfere with or crash the other. But the main reason has to do with the implementation.
.Net languages, being managed, are designed with a memory model such that the manager can be sure nothing from outside your app will inappropriately interfere with your app's memory. They're also designed using a separate thread for garbage collection, and this leads us to a place where your app is running as just one thread in a process. Even if you only use one thread, you could start up more, or load additional assemblies. So then, the purpose of an AppDomain is to encapsulate your app (and it's memory) within the process. It may be implemented as a object that keeps a reference to your assemblies, but that is separate from the concept.