△Hollis, 一個對Coding有著獨特追求的人△

這是Hollis的第?391?篇原創分享

作者 l Hollis

來源 l Hollis（ID：hollischuang）

不知道大家有沒有遇到過類似的問題，應用在剛剛啟動之后，前幾次訪問都會比較卡頓，RT都會比極高，在運行一段時間之后，就會順暢很多了。

這背后的原因是什么呢？

今天給大家介紹一種可能的原因，也是一種經常被別人忽略的原因，也是我們線上環境遇到過很多次的問題，那就是和JIT有關的。

JIT編譯

我們知道，想要把高級語言轉變成計算機認識的機器語言有兩種方式，分別是編譯和解釋，雖然Java轉成機器語言的過程中有一個步驟是要編譯成字節碼，但是，這里的字節碼并不能在機器上直接執行。

所以，JVM中內置了解釋器(interpreter)，在運行時對字節碼進行解釋翻譯成機器碼，然后再執行。

解釋器的執行方式是一邊翻譯，一邊執行，因此執行效率很低。為了解決這樣的低效問題，HotSpot引入了JIT技術（Just-In-Time）。

有了JIT技術之后，JVM還是通過解釋器進行解釋執行。但是，當JVM發現某個方法或代碼塊運行時執行的特別頻繁的時候，就會認為這是“熱點代碼”（Hot Spot Code)。然后JIT會把部分“熱點代碼”翻譯成本地機器相關的機器碼，并進行優化，然后再把翻譯后的機器碼緩存起來，以備下次使用。

這也是HotSpot虛擬機的名字的由來

那么，這和我們今天要講的問題有啥關系呢？

大家理解了JIT編譯的原理之后，其實可以知道，JIT優化是在運行期進行的，并且也不是Java進程剛一啟動就能優化的，是需要先執行一段時間的，因為他需要先知道哪些是熱點代碼。

所以，在JIT優化開始之前，我們的所有請求，都是要經過解釋執行的，這個過程就會相對慢一些。

而且，如果你們的應用的請求量比較大的的話，這種問題就會更加明顯，在應用啟動過程中，會有大量的請求過來，這就會導致解釋器持續的在努力工作。

一旦解釋器對CPU資源占用比較大的話，就會間接的導致CPU、LOAD等飆高，導致應用的性能進一步下降。

這也是為什么很多應用在發布過程中，會出現剛剛重啟好的應用會發生大量的超時問題了。

而隨著請求的不斷增多，JIT優化就會被觸發，這就是使得后續的熱點請求的執行可能就不需要在通過解釋執行了，直接運行JIT優化后緩存的機器碼就行了。

如何解決

那么，怎么解決這樣的問題呢？

主要有兩種思路：

1、提升JIT優化的效率

2、降低瞬時請求量

在提升JIT優化效率的設計上，大家可以了解一下阿里研發的JDK——Dragonwell。

這個相比OpenJDK提供了一些專有特性，其中一項叫做JwarmUp的技術就是解決JIT優化效率的問題的。

這個技術主要是通過記錄Java應用上一次運行時候的編譯信息到文件中，在下次應用啟動時，讀取該文件，從而在流量進來之前，提前完成類的加載、初始化和方法編譯，從而跳過解釋階段，直接執行編譯好的機器碼。

除了針對JDK做優化之外，還可以采用另外一種方式來解決這個問題，那就是做預熱。

很多人都聽說過緩存預熱，其實思想是類似的。

就是說在應用剛剛啟動的時候，通過調節負載均衡，不要很快的把大流量分發給他，而是先分給他一小部分流量，通過這部分流量來觸發JIT優化，等優化好了之后，再把流量調大。

總結

本文介紹了一下JIT優化的時機以及原理，我們今天討論的問題不是JIT優化導致的，而JIT優化的出現恰恰是要解決這樣的問題的。

但是這個知識點卻和JIT優化息息相關。或者說有些問題JIT優化并沒辦法徹底解決，我們可以幫助JIT優化做一些優化。

技術交流群

最近有很多人問，有沒有讀者交流群，想知道怎么加入。

最近我創建了一些群，大家可以加入。交流群都是免費的，只需要大家加入之后不要隨便發廣告，多多交流技術就好了。

目前創建了多個交流群，全國交流群、北上廣杭深等各地區交流群、面試交流群、資源共享群等。

有興趣入群的同學，可長按掃描下方二維碼，一定要備注：全國 Or 城市 Or 面試 Or 資源，根據格式備注，可更快被通過且邀請進群。

▲長按掃描

往期推薦 我開源的軟件只能我拿來賺錢92年清華本科，做了30年技術，43歲在CTO的位置上被優化！找了一年多工作，有些迷茫！360變相裁員！以代打卡為由強行裁員，不給賠償！

如果你喜歡本文,

請長按二維碼，關注?Hollis.

轉發至朋友圈，是對我最大的支持。

點個?在看?

喜歡是一種感覺

在看是一種支持

↘↘↘

總結

以上是生活随笔為你收集整理的阿里终面：为什么应用刚启动的时候比较卡，过一会就好了？的全部內容，希望文章能夠幫你解決所遇到的問題。

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