Understand appdomain

zhaozj2021-02-08  213

Now is a virtual machine era, Java is called JVM (Java virtual machine), and NET is called Framework. The control has two systems, and there are many different, but I am interested in the .NET called "Appdomain" in Dongdong. This concept is accurately understood, what is the meaning of .NET development? What do you need to do with it?

Microsoft's .NET documentation interpretation is quite simple (not very clearly J): "An application executable in it". Provide isolation, unload, and security boundaries for execution managed code. How do you understand? I think it is, I can have this concept:

1. Appdomain is the unique concept of .NET framework. Can't find any other technical system, it is Microsoft's own stuff. Many people think that they can be the same as the concept of processes, I don't agree: 1. "Process" is the concept of operating system, there is its own definition and function in the system of virtual machine / framework, apparently this understanding Appdomain is Error; Second, "There is no one in the application domain and thread, multiple threads can belong to an application domain, although the given thread is not limited to an application domain, but in any give Time, threads are executed in an application domain. "(Description in Net Framework SDK), if the" application field "here is changed to" process "?"

2, isolation. It is not blameful to directly set up the process, and AppDomain has the characteristics of code execution, just like the process. Appdomain's object, code can be considered to be isolated, even the code in an appdomain calls an object (data or method, etc.) of the other Appdomain, which requires "column set / distribution" in the DCOM (in inheritance relationship) AppDomain inherits from the MarshalByrefObject class). Every appdomain can be debugged, started, stopped, with its own default exception handling, an appdomain crashed, will not affect other appdomain. It can be understood as the "logical process" of .NET.

The different versions of the .NET allow the same application can coexist, eliminating so-called "DLL Hell". By creating different appdomain, we can make the version of 1.0 and 2.0 of a managed assembly simultaneously (as long as they do not have a particular resource for non-compatibility access access)

3, safety. Due to code isolation, a hazard code can be prevented from the impact of other appdomain. And you can assign a specific security allocation to determine access to the execution code in AppDomain for the accesses of the system security protection resource.

4, independence. Each AppDomain is allocated by the .NET's framework (application domain local storage). Any object can access the local storage area of ​​our current AppDomain, which is shared by objects in the appdomain, also including threads entering AppDomain (threads running on the same appdomain can communicate through this local storage).

5, the relationship between the process, thread, and assembly. The process belongs to a multi-to-one relationship, that is, multiple Appdomain, but appdomain can only exist in a process (obviously, just as the above: the process is different concepts). By default, if you don't have multiple Appdomain, a process starts automatically creates an appdomain. Thread execution can involve multiple Appdomain, but a specific time, the thread exists only in an appdomain, and the thread can enter other Appdomain. A certain instance of an assembly belongs to the specific Appdomain, loaded by AppDomain in its own range, and creates the corresponding object according to the assembly. AppDomain is an executive environment of the assembly, while the assembly as a static entity can be loaded by multiple Appdomain loading. Many humanities tell the relevant programming (but nothing to know what is appdomain), and the monks do not want to copy, basically involve appdomain's creation, uninstall, get the current AppDomain instance, create object call objects in AppDomain, AppDomain, load specific programs Coordination between set, executing program, AppDomain (callback, event, etc.). Can refer to some of the URLs I collected:

Appdomain reference

http://tech.ccidnet.com/pub/Article/c1136_a30763_p1.html

Http://www.yesky.com/softchannel/72342380484755456/20030819/1722679_2.shtml

Http://www.microsoft.com/china/msdn/library/dncscol/html/csharp05162002.asp

http://wwwb.pconline.com.cn/pcedu/empolder/gj/vb/doc/10712_2.htm

http://www.9cbs.net/develop/read_article.asp?id=19285

http://www.9cbs.net/develop/read_article.asp?id=13303

Reference in the SDK document:

MS-help: //ms.vscc/ms.msdnvs.2052/cpref/html/frlrfsystemappdomainclasstopic.htm

MS-help: //ms.vscc/ms.msdnvs.2052/cpref/html/frlrfsystemappdomainmemberstopic.htm

Knowing the previous discussion, in fact, in general, we don't need to pay attention to appdomain, but this concept appears in .NET in the case, there is reason to exist, then use Appdomain to use under the situation?

1. The assembly that needs to be quarantined, such as some particularly easy to cause crash, can consider running separately in a specific Appdomain

2, the assembly of different security levels, if you need to divide the security execution for your code, you can consider the code of different security levels to create an appdomain set different security information.

3. From the performance consideration, some assessments may consume a lot of resources. Although there is basically no resource consumption vulnerability in the hosted environment, there is always a case where a specific time access is densely consumed, and it can be considered to be created. Separate Appdomain, the unloading of AppDomain after the resource consumption exceeds the critical point, and adapts to the system operation requirements. ASP.NET is used to provide support to prevent the crash of an application from affecting other ASP.NET applications, while not restarting the system not restarting IIS does not affect the ASP.NET own service provided. Remove an appdomain to start a new AppDomain at the same time, ideally, you can implement a long-term online online (this is expensive UNIX characteristics, finally being "reference" by MS). 4, running simultaneously with different versions of the same app set. This is a big problem in the COM era. Now through appdomain, you can achieve two additional assemblies that have different versions in a process can achieve good compatibility.

5, dynamically load some programs.

Other applications waiting for everyone to add :)

转载请注明原文地址:https://www.9cbs.com/read-3066.html

New Post(0)