.NET CRL程序載入原理大揭秘
.NET這個詞語對我們不陌生吧，而.Net平臺下CLR程序程序怎么載入呢？這個有有些人就步知道了，在這里給大家分析以下原理。與傳統的Win32可執行程序中的本機代碼(Native Code)不同，微軟推出的.Net架構中，可執行程序的代碼是以類似Java Byte Code的 IL (Intermediate Language)偽代碼形式存在的。在.Net可執行程序載入后，IL代碼由CLR (Common Language Runtime)從可執行文件中取出， 交由JIT (Just-In-Time)編譯器，根據相應的元數據(Metadata)，實時編譯成本機代碼后執行。
因此，一個.NET CRL下的可執行程序的啟動過程可以分為三個步驟。
首先，Windows的可執行程序載入器(OS Loader)載入 PE (Portable Executable)結構的可執行文件映像(PE Image)，將執行權傳遞給CLR的支持庫中的Unmanaged Code。
其次，啟動或使用現有的CLR引擎，建立新的應用域(Application Domain)，將配件(Assembly)載入到此應用域中。
最后，將執行權從Unmanaged Code傳遞給Managed Code，執行配件的代碼。
下面我將詳細說明以上步驟。
自從Win95發布以來，可執行程序的PE結構就沒有發生大的改動。此次.Net平臺發布，也只是利用了PE結構中現有的預留空間，以保持PE結構的穩定，最大程度保持向后兼容。CLR程序在編譯后，將可執行程序入口直接以一個間接跳轉指令 ，指向mscoree.lib中的_CorExeMain函數（DLL將入口指向_CorDllMain函數）。因此CLR可執行程序在被OS Loader載入后，將_CorExeMain函數處理CLR引擎 ，啟動事宜。此函數將啟動或使用一個現有的CLR Host來加載IL代碼。常見的CLR Host有ASP.Net、IE、Shell、數據庫引擎等等，他們的作用是啟動一個CLR實例，管理在此CLR實例中運行的CLR程序。我們接著來看一看一個CLR Host是如何實際運作的。
CLR作為一個引擎，在同一臺計算機上是可以存在多個版本的，不同版本之間可以通過配置良好共存。在 ％windir％\Microsoft.NET\Framework （％windir％表示Windows系統目錄所在位置）目錄下我們可以看到以版本號為目錄名的多個CLR版本， 如％windir％\Microsoft.NET\Framework\v1.0.3705等等，也可以在注冊表的
- HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\policy\v1.0
鍵下查看詳細的版本兼容性.Name是Build號,Value是兼容的Build號. 而每一個CLR版本又分為Server和Workstation兩類運行庫, 我們等會講創建.NET CLR時會詳細談到. CLR Host在啟動CLR之前,必須通過一個startup shim的庫進行操作, 實際上就是mscoree.dll,他提供了版本無關的操作函數,以及啟動CLR所需 的支持,如CorBindToRuntimeEx函數. CLR Host通過shim的支持庫,將CLR引擎載入到進程中.具體函數如下
- STDAPI CorBindToRuntimeEx(LPCWSTR pwszVersion,
- LPCWSTR pwszBuildFlavor, DWORD startupFlags,
- REFCLSID rclsid, REFIID riid, LPVOID FAR *ppv);
參數pwszVersion指定要載入的CLR版本號,注意必須在前面帶一個小寫的"v", 如"v1.0.3705",可以通過查閱前面提到的注冊表鍵,獲取當前系統安裝的不同CLR 版本情況,或指定固定的CLR版本.也可以遞NULL給這個參數,系統將自動選擇最新版本的CLR載入. 參數pwszBuildFlavor則指定載入的CLR類型,"srv"和"wks". 前者適用于多處理器的計算機,能夠利用多CPU提高并行性能.對單CPU系統而言,無論指定哪種類型都會載入"wks",傳遞NULL也是如此. 參數startupFlags是一個組合參數.由多個標志位組成. STARTUP_CONCURRENT_GC標志指定是否使用并發的GC(Garbage Collection) 機制,使用并發GC能夠提高系統的用戶界面相應效率,適合窗口界面使用較多的程序. 但并發GC會因為無謂的線程上下文(Thread Context)切換損失效率.
以下三個參數用于指定配件載入優化策略.我們等會詳細討論.
- STARTUP_LOADER_OPTIMIZATION_SINGLE_DOMAIN = 0x1 << 1,
- STARTUP_LOADER_OPTIMIZATION_MULTI_DOMAIN = 0x2 << 1,
- STARTUP_LOADER_OPTIMIZATION_MULTI_DOMAIN_HOST = 0x3 << 1,
接著的三個參數用于獲取ICorRuntimeHost接口.
實際調用實例如下.
- CComPtr<ICorRuntimeHost> spHost;
- CHECK(CorBindToRuntimeEx(NULL, L"wks",
- STARTUP_LOADER_OPTIMIZATION_SINGLE_DOMAIN | STARTUP_CONCURRENT_GC,
- CLSID_CorRuntimeHost, IID_ICorRuntimeHost, (void **)&spHost));
這行代碼載入最高版本CLR的wks類型運行庫,為單應用域進行優化并使用并發GC機制. 前面提到了配件載入優化策略,要理解這個概念,我們必須先了解應用域的概念. 傳統Win程序中,資源的分配管理單位是進程,操作系統以進程邊界將應用程序實例隔離開, 單個進程的崩潰不會對其他進程產生直接影響,進程也不能直接使用其他進程的資源. 進程很好,但使用進程的代價太大,為此Win32引入了線程的概念.同一進程中的線程能夠共享資源,線程管理和切換的代價也遠遠小于進程.但因為在同一進程中,線程的崩潰會直接影響到其他線程的運行,也無法約束線程間數據的直接訪問等等. 為此,CLR Application Domain應用域的概念.應用域是介于進程和線程之間的一種邏輯上的概念.他既有線程輕巧,管理切換快捷的優點,也有進程在穩定性方面的優點,單個應用域的崩潰不會直接影響到同一進程中的其他應用域,應用域也無法直接訪問同一進程中的其他應用域的資源,這方面和進程完全相同. 而.NET CLR的管理就是完全面向應用域一級.CLR不能卸載(Unload)某個類型或配件, 必須以應用域為單位啟動/停止代碼,獲取/釋放資源.
CLR在執行一個配件時,會新建一個應用域,將此配件放入新的應用域.如果多個應用域同時使用到一個配件,就要涉及到前面提到的配件載入優化策略了.最簡單的方法是使用
STARTUP_LOADER_OPTIMIZATION_SINGLE_DOMAIN標志,每個應用域擁有一份獨立的配件的鏡像,這樣速度最快,管理最方便,但占用內存較多.相對的是所有應用域共享一份配件的鏡像,(使用STARTUP_LOADER_OPTIMIZATION_MULTI_DOMAIN標志) 這樣節約內存,但在此配件中存在靜態變量等數據時,因為要保證每個應用域有獨立的數 據, 所以會一定程度上影響效率.折中的方案是使用 (使用STARTUP_LOADER_OPTIMIZATION_MULTI_DOMAIN_HOST標志) 此時,只有那些有Strong Name的配件才會被多個應用域共享.
這里又涉及到一個概念Strong Name.他是一個配件的身份證明,他由配件的 名字/版本/culture以及數字簽名等組成.在配件發布時用以區別不同版本. 也在安全/版本控制等方面起到重要作用,以后有機會會專門講解.暫且跳過. 獲取了ICorRuntimeHost接口的指針后,我們可以以此指針取得當前/缺省應用域,
并可枚舉CLR引擎實例中所有的應用域.
【編輯推薦】
