簡介

Java虛擬機（JVM）是Java應用的運行環境，從一般意義上來講，JVM是通過規范來定義的一個虛擬的計算機，被設計用來解釋執行從Java源碼編譯而來的字節碼。更通俗地說，JVM是指對這個規范的具體實現。這種實現基于嚴格的指令集和全面的內存模型。另外，JVM也通常被形容為對軟件運行時環境的實現。通常JVM實現主要指的是HotSpot。

JVM規范保證任何的實現都能夠以同樣的方式解釋執行字節碼。其實現可以多樣化，包括進程、獨立的Java操作系統或者直接執行字節碼的處理器芯片。我們了解最多的JVM是作為軟件實現，運行在流行的操作系統平臺上（包括Windows、OS X、Linux和Solaris等）。

JVM的結構允許對一個Java應用進行更細微的控制。這些應用運行在沙箱（Sandbox）環境中。確保在沒有恰當的許可時，無法訪問到本地文件系統、處理器和網絡連接。遠程執行時，代碼還需要進行證書認證。

除了解釋執行Java字節碼，大多數的JVM實現還包含一個JIT（just-in-time 即時）編譯器，用于為常用的方法生成機器碼。機器碼使用的是CPU的本地語言，相比字節碼有著更快的運行速度。

雖然理解JVM不是開發或運行Java程序的必要條件，但是如果多了解一些JVM知識，那么就有機會避免很多性能上的問題。理解了JVM，實際上這些問題會變得簡單明了。

體系結構

JVM規范定義了一系列子系統以及它們的外部行為。JVM主要有以下子系統：

• Class Loader 類加載器。 用于讀入Java源代碼并將類加載到數據區。
• Execution Engine 執行引擎。 執行來自數據區的指令。

數據區使用的是底層操作系統分配給JVM的內存。

類加載器（Class Loader）

JVM在下面幾種不同的層面使用不同的類加載器：

• bootstrap class loader（引導類加載器）：是其他類加載器的父類，它用于加載Java核心庫，并且是唯一一個用本地代碼編寫的類加載器。
• extension class loader（擴展類加載器）：是bootstrap class loader加載器的子類，用于加載擴展庫。
• system class loader（系統類加載器）：是extension class loader加載器的子類，用于加載在classpath中的應用程序的類文件。
• user-defined class loader（用戶定義的類加載器）：是系統類加載器或其他用戶定義的類加載器的子類。

當一個類加載器收到一個加載類的請求，首先它會檢查緩存，確認該類是否已經被加載，然后把請求代理給它的父類。如果父類沒能成功的加載類，那么子類就會自己去嘗試加載該類。子類可檢查父類加載器的緩存，但父類不能看到子類所加載的類。之所類加載體系會這樣設計，是認為一個子類不應該重復加載已經被父類加載過的類。

執行引擎（Execution Engine）

執行引擎一個接一個地執行被加載到數據區的字節碼。為了保證字節碼指令對于機器來說是可讀的，執行引擎使用下面兩個方法：

• 解釋執行：執行引擎把它遇到的每一條指令解釋為機器語言。
• 即時編譯：如果一條指令經常被使用，執行引擎會把它編譯為本地代碼并存儲在緩存中。這樣，所有和這個方法相關的代碼都會直接執行，從而避免重復解釋。

盡管即時編譯比解釋執行要占用更多的時間，但是對于需要使用成千上萬次的方法，只需要處理一次。相比每次都解釋執行，以本地代碼的方式運行會節約很多執行時間。

JVM規范中并不規定一定要使用即時編譯。即時編譯也不是用于提高JVM性能的唯一的手段。規范僅僅規定了每條字節碼對應的本地代碼，至于執行引擎如何實現這一對應過程的，完全由JVM的具體實現來決定。

內存模型（Memory Model）

Java內存模型建立在自動內存管理的概念之上。當一個對象不再被一個應用所引用，垃圾回收器就會回收它，從而釋放相應的內存。這一點和其他很多需要自行釋放內存的語言有很大不同。

JVM從底層操作系統中分配內存，并將它們分為以下幾個區域：

• 堆空間（Heap Space）：這是共享的內存區域，用于存儲可以被垃圾回收器回收的對象。
• 方法區（Method Area）：這塊區域以前被稱作“永生代”（permanent generation），用于存儲被加載的類。這塊區域最近被JVM取消了。現在，被加載的類作為元數據加載到底層操作系統的本地內存區。
• 本地區（Native Area）：這個區域用于存儲基本類型的引用和變量。

一個有效的管理內存方法是把對空間劃分為不同代，這樣垃圾回收器就不用掃描整個堆區。大多數的對象的生命周期都很段短暫，那些生命周期較長的對象往往直到應用退出才需要被清除。

當一個Java應用創建了一個對象，這個對象是被存儲到“初生池”（eden pool）。一旦初生池存儲滿了，就會在新生代觸發一次minor gc（小范圍的垃圾回收）。首先，垃圾回收器會標記出那些“死對象”（不再被應用所引用的對象），同時延長所有保留對象的生命周期（這個生命周期長度是用數字來描述，代表了期所經歷過的垃圾回收的次數）。然后，垃圾回收器會回收這些死對象，并把剩余的活著的對象移動到“幸存池”（survivor pool），從而清空初生池。

當一個對象存活達到一定的周期后，它就會被移動到堆中的老生代：“終身代”（tenured pool）。最后，當終身代被填滿時，就會觸發一次full gc或major gc（完全的垃圾回收），以清理終身代。

（譯者注：一般我們把初生池和幸存池所在的區域合并成為新生代，把終身代所在的區域成為老生代。對應的，在新生代上產生的gc稱為minor gc，在老生代上產生的gc稱為full gc。希望這樣大家在其他地方看到對應的術語時能更好理解）

當垃圾回收（gc）執行的時候，所有應用線程都要被停止，系統產生一次暫停。minor gc非常頻繁，所以被優化的能夠快速的回收死對象，是新生代的內存的主要的回收方式。major gc運行起來就相對慢得多，因為要掃描非常多的活著的對象。垃圾回收器本身也有多種實現，有些垃圾回收器在一定情況下能更快的執行major gc。

堆的大小是動態的，只有堆需要擴張的時候才會從內存中分配。當堆被填滿時，JVM會重新給堆分配更多的內存，直到達到堆大小的上限，這種重新分配同樣會導致應用的短暫停止。

線程

JVM是運行在一個獨立的進程中的，但它可以并發執行多個線程，每個線程都運行自己的方法，這是Java必備的一個部分。以即時消息客戶端這樣一個應用為例，它至少運行兩個線程。一個線程用于等待用戶輸入，另一個檢查服務端是否有新的消息傳輸。再以服務端應用為例，有時一個請求可能要涉及多個線程并發執行，所以需要多線程來處理請求。

在JVM的進程中，所有的線程共享內存和其他可用的資源。每一個JVM進程在進入點（main方法）處都要啟動一個主線程，其他線程都從主線程啟動，成為執行過程中的一個獨立部分。線程可以再不同的處理器上并行執行，同樣也可以共享一個處理器，線程調度器負責處理多個線程共享一個處理器的情況。

很多應用（特別是服務端應用）會處理很多任務，需要并行運行。這些任務中有些是非常重要的，需要實時執行的。而另外一些是后臺任務，可以在CPU空閑時執行。任務是在不同的線程中運行的。舉例子來說，服務端可能有一些低優先級的線程，它們會根據一些數據來計算統計信息。同時也會啟動一些高優先級的進程用于處理傳入的數據，響應對這些統計信息的請求。這里可能有很多的源數據，很多來自客戶端的數據請求，每個請求都會使服務端短暫的停止后臺計算的線程以響應這個請求。所以，你必須監控在運行的線程數目并且保證有足夠的CPU時間來執行必要的計算。

（譯者注：這一段在原文中是在性能優化的章節，譯者認為這可能是作者的不小心，似乎放在線程的章節更合適。）

性能優化

JVM的性能取決于其配置是否與應用的功能相匹配。盡管垃圾回收器和內存回收進程是自動管理內存的，但是你必須掌管它們的頻率。通常來說，你的應用可使用的內存越多，那么這些會導致應用暫停的內存管理進程需要起作用的就越少。

如果垃圾回收發生的頻率比你想的要多很多，那么可以在啟動JVM的時候為其配置更大的最大堆大小值。堆被填滿的時間越久，就越能降低垃圾回收發生的頻率。最大堆大小值可以在啟動JVM的時候，用-Xmx參數來設定。默認的最大堆大小是被設置為可用的操作系統內存的四分之一，或者最小1GB。

如果問題出在經常重新分配內存，那么你可以把初始化堆大小設置為和最大堆大小一樣。這就意味著JVM永遠不需要為堆重新分配內存。但這樣做就會失去動態堆大小適配的優化，堆的大小從一開始就被固定下來。配置初始化對大小是在啟動JVM，用-Xms來設定。默認初始化堆大小會被設定為操作系統可用的物理內存的六十四分之一，或者設置一個最小值。這個值是根據不同的平臺來確定的。

如果你清楚是哪種垃圾回收（minor gc或major gc）導致了性能問題，可以在不改變整個堆大小的情況下設定新生代和老生代的大小比例。對于需要產生大量臨時對象的應用，需要增大新生代的比例（當然，后果是減小了老生代的大小）。對于長生命周期對象較多的應用，則需增大老生代的比例（自然需要減少新生代的大小）。以下幾種方法可以用來設定新生代和老生代的大小：

• 在啟動JVM時，使用-XX:NewRatio參數來具體指定新生代和老生代的大小比例。比如，如果想讓老生代的大小是新生代的五倍，則設置參數為-XX:NewRatio=5，默認這個參數設定為2（即老生代占用堆空間的三分之二，新生代占用三分之一）。
• 在啟動JVM時，直接使用-Xmn參數設定初始化和最大新生代大小，那么堆中的剩余大小即是老生代的大小。
• 在啟動JVM時，直接使用-XX:NewSize和-XX:MaxNewSize參數設定初始化和最大新生代大小，那么堆中的剩余大小即是老生代的大小。

每一個線程都有一個棧，用于保存函數調用、返回地址等等，這些棧有著對應的內存分配。如果線程過多，就會導致OutOfMemory錯誤。即使你有足夠的空間的堆來存放對象，你的應用也可能會因為創建一個新的線程而崩潰。這種情況下，需要考慮限制線程中的棧大小的最大值。線程棧大小可以在JVM啟動的時候，通過-Xss參數來設置，默認這個值被設定為320KB至1024KB之間，這和平臺相關。

性能監控

當開發或運行一個Java應用的時候，對JVM的性能進行監控是很重要的。配置JVM不是一次配置就萬事大吉的，特別是你要應對的是Java服務器應用的情況。你必須持續的檢查堆內存和非堆內存的分配和使用情況，線程數的創建情況和內存中加載的類的數據情況等。這些都是核心參數。

使用Anturis控制臺，你可以為任何的硬件組件上運行的JVM配置監控（例如，在一臺電腦上運行的一個Tomcat網頁服務器）。

JVM監控可以使用以下衡量標準：

• 總內存使用情況（MB）：即JVM使用的總內存。如果JVM使用了所有可用內存，這項指標可以衡量底層操作系統的整體性能。
• 堆內存使用（MB）：即JVM為運行的Java應用所使用的對象分配的所有內存。不使用的對象通常會被垃圾回收器從堆中移除。所以，如果這個指數增大，表示你的應用沒有把不使用的對象移除或者你需要更好的配置垃圾回收器的參數。
• 非堆內存的使用（MB）：即為方法區和代碼緩存分配的所有內存。方法區是用于存儲被加載的類的引用，如果這些引用沒有被適當的清理，永生代池會在每次應用被重新部署的時候都會增大，導致非堆的內存泄露。這個指標也可能指示了線程創建的泄露。
• 池內總內存（MB）：即JVM所分配的所有變量內存池的內存和（即除了代碼緩存區外的所有內存和）。這個指標能夠讓你明確你的應用在JVM過載前所能使用的總內存。
• 線程：即所有有效線程數。舉個例子，在Tomcat服務器中每個請求都是一個獨立的線程來處理，所以這個衡量指標可以表示當前有多少個請求數，是否影響到了后臺低權限的線程的運行。
• 類：即所有被加載的類的總數。如果你的應用動態的創建很多類，這可能是服務器內存泄露的一個原因。

相關文章

• 從Java代碼到字節碼（1）
• 高吞吐低延遲Java應用的垃圾回收優化
• JVM的重排序
• Linux HotSopt虛擬機GC線程的CPU占用率
• 如何估算內存消耗
• JVM最簡生存指南
• 尋找導致80JVM WebSphere集群崩潰的罪魁禍首——Oracle JDBC內存泄露
• 在運行期通過反射了解JVM內部機制
• 2013年ImportNew最受歡迎的10篇文章
• 性能調優、虛擬機、垃圾回收、軟硬件協調相關文章和視頻 — Part1