CLR和JRE的運行機制的初步總結
--------------------------------------------------------------------------------
概念比較：
Java C#
byte code IL(字節碼，中間語言)
jvm.dll mscrolib.dll,mscrojit.dll(虛擬機)
JRE CLR(運行環境)
JDK .Net Framework(開發框架)
package assembly(類庫，程序集)
一、關於類庫的版本治理問題
Java和C#代碼運行要依靠其運行環境(JRE,CLR)和運行環境帶的基礎類庫(C#稱為配件或者程序集Assembly)，此外還會有一些第三方的類庫或者自己開發的類庫。假如運行環境版本不一致，或者引用的類庫版本不一致都會帶來程序不能正常運行。比如一個Java程序是在JDK1.2上開發，假如在JRE1.4上運行，一般情況下可以向下兼容，但也有例外，有些GUI程序在JDK1.4上面運行結果很可能會不同。
JRE的版本治理
Java的解決辦法是每個程序自己攜帶一套JRE。
我的機器上已經被安裝了好多套JRE和JDK了(JDK包括了同版本的JRE，此外還包括有編譯器和其它工具)，它們分別是：
BEA Weblogic Server 7.0 自帶一套 JDK1.3.1_02
我下載了一套最新的JDK1.4.1_02
JBuilder9自帶一套JKD1.4.1_02
Oracle8.1.7自帶一套JRE1.1.7
Ration Rose自帶一套JDK1.3
DreamWeaver自帶一套JDK1.3
6套JRE，每套JRE都被各自安裝到不同的目錄，不會互相影響。當在控制台執行java.exe，操作系統尋找JRE的方式如下：
先找當前目錄下有沒有JRE
再找父目錄下有沒有JRE
接著在PATH路徑中找JRE
注冊表HKEY_LOCAL_MACHINESOFTWAREJavaSoftJava Runtime Environment 查看CurrentVersion的鍵值指向哪個JRE
最常用的是在PATH路徑中找JRE，一般情況下，自己的程序運行之前都會先在批處理文件裡面臨時設置PATH，把自己用的JRE放到PATH路徑最前面，所以肯定會運行自己帶的JRE，不會造成版本混亂。
.Net Framework的版本治理
.Net Framework被固定安裝在C:WinntMicrosoft.NETFrameworkv版本號目錄下，並且在同一台機器只能安裝一套，要安裝1.1版本的.Net Framework，就必須先刪除1.0的。聽說剛發行的.Net Framework1.1已經對1.0做了很多改進，甚至基礎類庫的層次也有所變動。看來在舊版本的.Net Framework開發的程序將來往新版本上面遷移的時候少不了修改程序代碼。
JRE的基礎類庫
JRE自帶的基礎類庫主要是JRElib
t.jar這個文件，包括了Java2平台標准版的所有類庫。和JRE的版本一致。
.Net Framekwork的核心類庫
.Net Framekwork的核心類庫被放置在C:Winntassemblygac目錄下，按照不同的名稱空間放在不同目錄中，不像JRE打成了一個包。並且可以同時存在不同的版本，例如：
某類庫1.0版本 C:Winntassemblygac名稱1.0名稱.dll
某類庫1.1版本 C:Winntassemblygac名稱1.1名稱.dll
這樣做，雖然很靈活，可以隨時把類庫更新到最新的狀態，但是很輕易帶來版本治理的復雜度，造成版本不一致。
JRE類庫的查找方法和版本治理
JRE中由ClassLoader負責查找和加載程序引用到的類庫，基礎類庫ClassLoader會到rt.jar中自動加載，其它的類庫，ClassLoader在環境變量CLASSPATH指定的路徑中搜索，按照先來先到的原則，放在CLASSPATH前面的類庫先被搜到，Java程序啟動之前建議先把PATH和CLASSPATH環境變量設好，OS通過PATH來找JRE，確定基礎類庫rt.jar的位置，JRE的ClassLoader通過CLASSPATH找其它類庫。但有時候會出現這樣的情況，希望替換基礎類庫中的類庫，那麼也可以簡單的通過-Djava.endrosed.path=...參數傳遞給java.exe，於是ClassLoader會先於基礎類庫使用java.endrosed.path參數指定路徑的類庫。因此Java的版本治理是非常簡單有效的，也許很原始，不過很好用，簡單就不輕易出錯。(所以我很希奇Eric Ramond為什麼批評Java的類庫治理機制，他還居然批評Java的接口，令人懷疑他對Java的了解程度)
.Net Framework的類庫治理機制
.Net Framework的類庫治理機制相當強大和復雜，分為私有類庫和共享類庫。
私有類庫就放在exe程序當前路徑下，或其相對路徑中，只有當前程序可見。
共享類庫需要在GAC(Global Assembly Cache)中注冊，注冊過程比較復雜，首先要用工具生成公開/私有密鑰對，然後結合密鑰和類庫版本號連編，最後使用工具注冊到GAC中好以後,會被放在"C:Winntassemblygac類庫的名稱空間版本號"目錄下，不同的類庫版本在注冊的時候會按照版本號分開放置：
某類庫1.0版本 C:Winntassemblygac名稱1.0名稱.dll
某類庫1.1版本 C:Winntassemblygac名稱1.1名稱.dll
也就是可以同時存在一個類庫的n個版本，至於在程序中用哪個版本，在程序的配置文件中聲明，CLR會根據聲明來調用相應的版本的類庫。我覺得.Net實現方法未免太復雜了一些，將所有共享類庫都塞到一個系統目錄下，並且同一個類庫還有n個版本，將來.Net第三方開發的類庫逐漸豐富起來以後，.Net類庫的GAC也會越來越龐大，會不會也搞得和Windows注冊表一樣難以維護？軟件發布到服務器上的時候，類庫要再注冊一次，服務器會逐漸形成一個龐大的樹狀的GAC，GAC裡面存放著組件的n個版本。試想經過一段時間之後，C:Winntassemblygac目錄會越來越龐大，有的組件甚至有n個版本都放在那裡，你又不敢隨便刪除，不知道是不是有程序需要使用，我不明白MS為什麼要把這麼簡單的事情搞到這麼復雜？
綜上所述，Java的版本治理方式簡單而有效，C#的版本治理方式功能強大，不過是不是太復雜了？會不會搞成第二個注冊表一樣的東西？
二、虛擬機啟動和加載類庫的方式
Java的虛擬機啟動和加載類庫
在Console執行java.exe xxx命令以後，如前所述的尋找JRE，OS找到JRE目錄，根據java.exe的傳遞參數，選擇加載Server版的jvm.dll還是Client版的jvm.dll，然後加載jvm.dll，把控制權交給jvm.dll。
接下來，jvm.dll進行初始化，分配內存等等動作，然後在CLASSPATH路徑中尋找class，找到class以後，尋找class中的程序入口點Main函數，然後從Main函數執行程序，在執行過程中，使用ClassLoader動態加載一系列引用到的類。當調用到native方法時，jvm.dll告訴OS在JREin目錄下尋找某某DLL文件，調入內存，於是實現了JNI調用。
.Net的虛擬機的啟動推測
我對.Net的虛擬機的啟動過程還一知半解，自己寫了一些例程，並且用內存工具來檢測觀察，推測.Net的運行機制，先來拋磚引玉，請熟悉Windows平台編程的朋友指教。.Net有3個目錄中的文件在執行的時候會被加載
1、C:WINNTMicrosoft.NETFrameworkv版本號
該目錄下的mscorlib.dll,mscorrsn.dll,mscorwsk.dll,mscorjit.dll是核心DLL，大概是運行虛擬機的必要文件，其中mscrolib.dll是入口點。此外，該目錄下還有一些.Net的System名稱空間的IL類庫，與C:Winntassemblygac相應目錄下的IL類庫完全一樣，這些是最核心的基礎類庫。.Net的編譯器，檢查器等等工具軟件也在該目錄，推測System名稱空間的核心類庫之所以在這個目錄下copy一份是因為作為.Net的編譯器等工具的私有類庫之用。
2、C:Winntassemblygac
該目錄下放置.Net共享類庫，如前所述
3、C:Winntassembly
ativeimages_.Net版本號
在該目錄下也有一些以System名稱空間開頭的核心類庫，推測是MS為了加快CLR的執行效率把核心類庫進行本地化，編譯為native image的同名DLL。可以觀察到該目錄下的同名DLL文件，比GAC目錄下的同名DLL文件體積大，可能是因為link底層DLL庫的緣故。
某核心類庫 C:Winntassembly
ativeimages_.Net版本號名稱空間.Net版本號_散列碼名稱.dll
另外值得注重的地方是有兩個mscorlib.dll
1、C:WINNTMicrosoft.NETFrameworkv版本號mscrolib.dll (1.88MB)
2、C:WINNTassemblyNativeImages1_v版本號mscorlib版本號__散列碼mscrolib.dll (3.07MB)
mscrolib.dll (1.88MB)還是一個IL碼的版本，所以映射了一個native的版本的mscrolib.dll (3.07MB)，來加快CLR的速度。
當IL的exe程序被雙擊執行時，OS Loader讀入程序，識別出是IL，根據IL內部的引用定義，加載mscorlib.dll，而mscorlib.dll也是IL，內部引用C:winntsystem32mscoree.dll，於是再加載mscoree.dll，然後把控制權交給mscoree.dll，mscoree.dll接著加載mscrorsn.dll，mscrowsk.dll，mscrojit.dll，為了加快mscorlib.dll的調用，加載mscorlib.dll的native image版本，然後由mscorlib.dll接管控制權(不知道這兩個mscorlib.dll是如何來上管IL，下連native code的？)最後尋找IL碼程序的入口點Main函數，開始執行程序，在執行過程中，使用Class Loader動態加載一系列引用到的類，在當前路徑下，在共享類庫的GAC中查找等等。
這裡和jvm.dll不同的一點是，jvm.dll加載的基礎類庫和加載其它類庫方式完全一樣，全部都是字節碼的class。而mscrolib.dll加載以System名稱開頭的核心類庫的時候，使用了“不正當競爭手法”。mscrolib.dll從GAC中加載共享核心類庫之後，又C:Winntassembly
ativeimages_.Net版本號名稱空間 目錄下加載了核心類庫的native版本，這樣一來，自然CLR運行起來要快多了。非凡是圖形圖像類庫全部都有native映射版本，所以CLR上運行GUI焉能不快？
對比CLR和JRE的加載過程，比較不同的地方是mscorlib.dll和System核心類庫都有一個native image，可能這是CLR運行速度比較快的一個主要原因吧。
分析完以後有一個非凡明顯的感受，Java的底層運行機制設計的非凡簡單，而.Net的底層運行機制設計的非凡復雜。但是在企業層剛好相反，J2EE設計的非凡復雜，而.Net卻設計的非凡簡單，真是有意思！
Java的底層機制設計雖然簡單，但是很健壯，.Net設計使得它的CLR速度快，類庫治理功能強大，但是不是比Java更優秀，還要等以後慢慢看了。
注：
我查了一下《.Net Essential》這本書，上面提到這樣的說法。
MS更新了Windows各個版本的OS Loader程序，使得OS Loader可以識別.Net PE格式的exe文件，當執行Windows Native PE格式的exe文件的時候，OS Loader按照以往的方式加載系統DLL。假如是.Net PE格式的exe文件，OS Loader加載mscorlib.dll，然後把控制權交給mscorlib.dll。
