幾個月前，我正在閱讀Java中的復雜事件處理以及實現低延遲的方法。 在我長達一個小時的研究結束時，我發現即使您的應用程序編寫正確并且您的方法主要在0（log n）的時間內運行，并且您正在使用某些前沿的硬件解決方案，但仍會花費一些時間。 VM在解釋字節碼期間。

從好的方面來說，Java被解釋了，它的字節碼是跨JVM兼容的，但是我們也知道，因此，我們注定會在某些地方丟失某些東西。 我們的JVM讀取解釋的字節碼并每次運行。 顯然，這需要時間。

但是考慮到我們友好的鄰居JIT編譯器（服務器或客戶端）會注意常用的方法，并且發現方法被調用了太多次時 ，它會將其編譯為本機代碼，而不是依賴JVM，因此它的性能還不錯。一直在字節碼上。

使用vm參數配置“太多次”的數字

<-XX:CompileThreshold

默認值為1500 。 一個自然的猜測是減少數量將意味著更多的方法更快地轉換為本地代碼，這意味著更快的應用程序，但事實并非如此。 相當低的數字將意味著服務器由于JIT編譯太多方法（畢竟可能很少經常使用）而花費的時間非常慢，并且由于本機代碼駐留在內存中，因此您的應用程序將榮獲“記憶殺手”獎，并以緩慢的痛苦死亡。 稍作谷歌搜索就可以發現100左右的數字還不錯。 同樣，這取決于您的應用程序以及使用模式和流量。

忘了提及，成為JIT本機編譯候選對象的最小編譯單元是一種方法。 不是一個障礙。 因此，長期使用脂肪的方法–祝您好運！

實際上，這種JIT編譯并非一go而就。 它有兩個整潔的階段：

1）每次調用方法時，其計數器都會增加1，并在達到閾值后不久，JIT會進行第一次編譯 。

2）第一次編譯后，計數器將重置為0，然后再次遞增。 在第二個周期中，當JIT達到閾值時，它將進行第二輪編譯 –這次具有更激進和令人敬畏的優化（對不起–無法在此處提供很多詳細信息）

如果您使用的是JDK 7，并且您的計算機在多核上運行（我不知道為什么不這樣做），則可以使用以下標志來加快本機編譯過程

-server -XX:+TieredCompilation

考慮到可用選項的數量，我不能聲稱自己是JVM調優的專家。 因此，如果您覺得有用或不正確，請留下您的評論。

別忘了分享！

參考：通過我們的JCG合作伙伴 Arun Manivannan的Rerun.me博客為您的JVM熱身-超快速生產服務器和IDE 。