???上一篇文章中Aicken為大家介紹了.Net平臺的垃圾回收機制與其對性能的影響，這一篇中將繼續為大家介紹.Net平臺的另一批黑馬—JIT。
???有關JIT的機制分析
???● 機制分析
???以C#為例，在C#代碼運行前，一般會經過兩次編譯，第一階段是C#代碼向MSIL的編譯，第二階段是IL向本地代碼的編譯。第一階段的編譯成果是生成托管模塊，第二階段的編譯成果是生成本地代碼以供運行，從這里各位同學可以看出，第一階段生成的MSIL是不能直接運行的。必須指出的是JIT在第一次編譯IL后，會修改對應方法相應的內存地址入口，下一次需要執行這個方法時，CLR會直接訪問對應的內存地址，而不會經過JIT了。
???以Load()方法為例，假如Load()方法中調用了兩次同類型中的方法：
Void Load()
{
???A.a1("First");
???A.a1("Second");
}
static class A
{
???Public void a1(string str){}
???Public void a2(string str){}
???Public void a3(string str){}
}
???運行時，操作系統會根據托管模塊中各種頭信息，裝載相應的運行時框架，Load()被加載，由于是第一次加載，這會觸發對Load()的即時編譯，JIT會檢測Load()中引用的所有類型，并結合元數據遍歷這些類型中定義的所有方法實現，并用一個特殊的HashTable(僅用于理解)儲存這些類型方法與其對應的入口地址(在未被JIT前，這個入口地址為一個預編譯代理(PreJitStub)，這個代理負責觸發JIT編譯)，根據這些地址，就可以找到對應的方法實現。
???在初始化時，HashTable中各個方法指向的并不是對應的內存入口地址，而是一個JIT預編譯代理，這個函數負責將方法編譯為本地代碼。注意，這里JIT還沒有進行編譯，只是建立了方法表！

?

圖2方法表、方法描述、預編譯代理關系

???圖2中所示的MS核心引擎指的是一個叫做MSCorEE的DLL，即Microsoft .NET Runtime Execution Engine，它是一個橋接DLL，連同mscorwks.dll主要完成以下工作：
???1.查找程序集中包含的對應類型清單，并調用元數據遍歷出包含的方法。
???2.結合元數據獲得這個方法的IL。
???3.分配內存。
???4.編譯IL本地代碼，并保存在第3步所分配的內存中。
???5.將類型表(就是指上文中提到的HashTable)中方法地址修改為第3步所分配的內存地址。
???6.跳轉至本地代碼中執行。
???所以隨著程序的運行時間增加，越來越多的方法的IL被編譯為本地代碼，JIT的調用次數也會不斷減少。
???下面借助WinDbg來證實以上的說法，加載WinDbg的過程略。以下測試源代碼可以從這里下載http://files.cnblogs.com/isline/IsLine.JITTester.rar
namespace JITTester
{
???public partial class Form1 : Form
???{
?????? public Form1()
??????{
?????????InitializeComponent();
??????}
??????private void Form1_Load(object sender, EventArgs e)
??????{
??????}
??????private void GO_Click(object sender, EventArgs e)
??????{
?????????new A().a1();
?????????lb_msg.Text = "調用完畢!";
??????}
???}
???class A
???{
??????public void a1() { }
??????public C a2 = new C();
???}
???class B
???{
??????public void b1() { }
??????public void b2() { }
???}
???class C
???{
??????public void c1() { }
?????? public void c2() { }
???}
}
???使用name2ee命令遍歷所有已加載模塊，如下圖：

?

圖3 查看類型信息

???回車后注意高亮區域的信息：

?

圖4 JIT前A類型的信息

???高亮區域顯示的是“”，這說明雖然運行和程序，但未點擊按鈕時，A類型未被JIT，因為它還沒有入口地址。這一點體現了即時、按需編譯的思想。
???同樣，!name2ee *!JITTester.B和!name2ee *!JITTester.C命令會得到同樣的結果。
???好，現在繼續，Detach Debuggee進程，并回到程序中點擊“GO”按鈕

?

圖5 點擊按鈕

???然后重新附加進程，這時程序已經調用了new A().a1()方法，并重新執行令!name2ee *!JITTester.A ，注意高亮部分

?

圖6 JIT后A類型的信息>

???和圖4中的信息比較，圖6中的方法表地址已經變為JIT后的內存地址，這時圖2中的Stub槽將被一條強制跳轉語句替換，跳轉目標與該地址有關。這一點說明JIT在大多情況下，只編譯一次代碼。
???同樣命令查看B類型：

?

圖7 JIT后B類型的信息

???該類型未被調用，所以還未被JIT。
???C類型：

?

圖8 JIT后C類型的信息

???由于實例化A類型時和C類型相關，所以C類型已經JIT了。
???這就是一個類型被JIT的全部過程。
???● 性能影響分析
???通過以上的分析，大家已經能夠了解，即時編譯這個過程是在運行時發生的，這會不會對性能產生影響呢？事實上答案是雖然是肯定的，但這種開銷物有所值，并且如上所說的，JIT在第一次編譯IL后，會修改對應方法相應的內存地址入口(繞口啊~~)，下一次需要執行這個方法時，CLR會直接訪問對應的內存地址，而不會經過JIT了。
???1.JIT所造成的性能開銷并不顯著。
???2.JIT遵循計算機體系理論中兩個經典理論：局部性原理與8020原則。局部性原理指出，程序總是趨向于使用最近使用過的數據和指令，這包括空間的和時間的，將局部性原理引申可以得出，程序總是趨向于使用最近使用過的數據和指令，以及這些正在使用的數據和指令臨近的數據和指令(憑印象寫的，但不曲解原意)；而8020原則指出，系統大多數時間總是花費80%的時間去執行那20%的代碼。
???根據這兩個原則，JIT在運行時會實時的向前、后優化代碼，這樣的工作只有在運行時才可以做到。
???3.JIT只編譯需要的那一段代碼，而不是全部，這樣節約了不必要的內存開銷。
???4.JIT會根據運行時環境，即時的優化IL代碼，即同樣的IL代碼運行在不同CPU上，JIT編譯出的本地代碼是不同的，這些不同代碼面向自己的CPU做出了優化。
???5.JIT會對代碼的運行情況進行檢測，并對那些特殊的代碼經行重新編譯，在運行過程中不斷優化。

???此外你可以利用NGen.exe創建托管程序集的本機映像，運行該程序集時，就會自動使用該本機映像而不是JIT它們。這聽起來似乎很美妙，但是你必須做好以下準備：
???1.當FrameWork版本、CPU類型、操作系統版本發生變化時，.Net會恢復JIT機制。
???2.NGen.exe工具并不能避免發布IL，事實上，即使使用NGen.exe工具，CLR依然會使用到元數據和IL。
???3.忽略了局部性原理(上一節中提到的)，系統會加載整個映像文件到內存中，并很可能重定位文件，修正內存地址引用。
???4.NGen.exe生成的代碼無法在運行時進行優化，無法直接訪問靜態資源，也無法在應用程序域之間共享程序集。
???所以，除非你已十分清楚程序性能是由于首次編譯造成的性能問題，否則盡量不要人工生成本地代碼。
???JIT很優秀，它不但有編譯的本事，還會根據內存資源情況換出使用率低的代碼，節省資源，這對于一些基于.Net平臺的電子產品是很重要的。基于B/S模式運行的系統，如果使用率較高，可以基本忽略JIT帶來的性能損失，因為根據局部性原理與8020原則，常用的模塊都是編譯完畢的，只有那些不常用的模塊，在第一次使用時會被編譯，并損失用一些時間。

未完

????? 下一篇中，Aicken將會為大家介紹.Net Exception機制、字符串駐留機制以及其帶來的性能問題，敬請期待。

????? 我是Aicken(李鳴) 請您繼續關注我的下一篇文章。

?

“.Net Discovery 系列”是講解.Net平臺本質的文章，現在已經有：

??? .Net Discovery 系列之七--深入理解.Net垃圾收集機制(拾貝篇) 發布在新年第一秒

??? .Net Discovery 系列之五--Me JIT(深入淺出.Net JIT 上)

??? .Net Discovery 系列之六--Me JIT(深入淺出.Net JIT 下)

??? .Net Discovery 系列之三--深入理解.Net垃圾收集機制(上)

??? .Net Discovery 系列之四--深入理解.Net垃圾收集機制(下)

??? .Net Discovery 系列之一--string從入門到精通(上)

??? .Net Discovery 系列之二--string從入門到精通(下)

轉載于:https://www.cnblogs.com/isline/archive/2010/04/07/1705966.html

總結

以上是生活随笔為你收集整理的.Net Discovery系列之十一-深入理解平台机制与性能影响 (中)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。