幾個(gè)月前，我正在閱讀Java中的復(fù)雜事件處理以及實(shí)現(xiàn)低延遲的方法。 在我長(zhǎng)達(dá)一個(gè)小時(shí)的研究結(jié)束時(shí)，我發(fā)現(xiàn)即使您的應(yīng)用程序編寫(xiě)正確并且您的方法主要在0（log n）的時(shí)間內(nèi)運(yùn)行，并且您正在使用某些前沿的硬件解決方案，但仍會(huì)花費(fèi)一些時(shí)間。 VM在解釋字節(jié)碼期間。

從好的方面來(lái)說(shuō)，Java被解釋了，它的字節(jié)碼是跨JVM兼容的，但是我們也知道，因此，我們注定會(huì)在某些地方丟失某些東西。 我們的JVM讀取解釋的字節(jié)碼并每次運(yùn)行。 顯然，這需要時(shí)間。

但是考慮到我們友好的鄰居JIT編譯器（服務(wù)器或客戶端）會(huì)注意常用的方法，并且發(fā)現(xiàn)方法被調(diào)用了太多次時(shí) ，它會(huì)將其編譯為本機(jī)代碼，而不是依賴JVM，因此它的性能還不錯(cuò)。一直在字節(jié)碼上。

使用vm參數(shù)配置“太多次”的數(shù)字

<-XX:CompileThreshold

默認(rèn)值為1500 。 一個(gè)自然的猜測(cè)是減少數(shù)量將意味著更多的方法更快地轉(zhuǎn)換為本地代碼，這意味著更快的應(yīng)用程序，但事實(shí)并非如此。 相當(dāng)?shù)偷臄?shù)字將意味著服務(wù)器由于JIT編譯太多方法（畢竟可能很少經(jīng)常使用）而花費(fèi)的時(shí)間非常慢，并且由于本機(jī)代碼駐留在內(nèi)存中，因此您的應(yīng)用程序?qū)s獲“記憶殺手”獎(jiǎng)，并以緩慢的痛苦死亡。 稍作谷歌搜索就可以發(fā)現(xiàn)100左右的數(shù)字還不錯(cuò)。 同樣，這取決于您的應(yīng)用程序以及使用模式和流量。

忘了提及，成為JIT本機(jī)編譯候選對(duì)象的最小編譯單元是一種方法。 不是一個(gè)障礙。 因此，長(zhǎng)期使用脂肪的方法–祝您好運(yùn)！

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

1）每次調(diào)用方法時(shí)，其計(jì)數(shù)器都會(huì)增加1，并在達(dá)到閾值后不久，JIT會(huì)進(jìn)行第一次編譯 。

2）第一次編譯后，計(jì)數(shù)器將重置為0，然后再次遞增。 在第二個(gè)周期中，當(dāng)JIT達(dá)到閾值時(shí)，它將進(jìn)行第二輪編譯 –這次具有更激進(jìn)和令人敬畏的優(yōu)化（對(duì)不起–無(wú)法在此處提供很多詳細(xì)信息）

如果您使用的是JDK 7，并且您的計(jì)算機(jī)在多核上運(yùn)行（我不知道為什么不這樣做），則可以使用以下標(biāo)志來(lái)加快本機(jī)編譯過(guò)程

-server -XX:+TieredCompilation

考慮到可用選項(xiàng)的數(shù)量，我不能聲稱自己是JVM調(diào)優(yōu)的專家。 因此，如果您覺(jué)得有用或不正確，請(qǐng)留下您的評(píng)論。

別忘了分享！

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

翻譯自: https://www.javacodegeeks.com/2012/10/warming-up-your-jvm-superfast.html

總結(jié)

以上是生活随笔為你收集整理的预热您的JVM –超快速生产服务器和IDE的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。