簡(jiǎn)介

JVM是Java Virtural Machine（Java 虛擬機(jī)）的縮寫，JVM是一種用于計(jì)算設(shè)備的規(guī)范，它是一個(gè)虛構(gòu)出來的計(jì)算機(jī)，是通過在實(shí)際的計(jì)算機(jī)上仿真模擬各種計(jì)算機(jī)功能來實(shí)現(xiàn)的。

Java語言的一個(gè)非常重要的特點(diǎn)就是平臺(tái)無關(guān)性。而實(shí)現(xiàn)這一特點(diǎn)的關(guān)鍵就是Java虛擬機(jī)。一般的高級(jí)語言如果要在不同的平臺(tái)上運(yùn)行，至少需要編譯成不同的目標(biāo)代碼。而引入Java語言虛擬機(jī)后，Java語言在不同平臺(tái)上運(yùn)行時(shí)不需要重新編譯。Java語言使用Java虛擬機(jī)屏蔽了與具體平臺(tái)相關(guān)的信息，使得Java語言編譯程序只需生成在Java虛擬機(jī)上運(yùn)行的目標(biāo)代碼（字節(jié)碼），就可以在多種平臺(tái)上不加修改地運(yùn)行。Java虛擬機(jī)在執(zhí)行字節(jié)碼時(shí)，把字節(jié)碼解釋成具體平臺(tái)上的機(jī)器指令執(zhí)行。這就是Java的能夠“一次編譯，到處運(yùn)行”的原因。

總體概述

JVM總體上是由四個(gè)部分組成，其中運(yùn)行時(shí)數(shù)據(jù)區(qū)是我們關(guān)注的地方。

• 類裝載子系統(tǒng)（ClassLoader）
• 運(yùn)行時(shí)數(shù)據(jù)區(qū)
  • 方法區(qū)（Method Area）
  • JAVA堆（Java Heap）
  • 虛擬機(jī)棧（JVM Stack）
  • 程序計(jì)數(shù)器
  • 本地方法棧（Native Method Stack
• 執(zhí)行引擎
• 垃圾收集

JVM體系結(jié)構(gòu)

類裝載子系統(tǒng)

Class Loader類加載器負(fù)責(zé)加載.class文件，class文件在文件開頭有特定的文件標(biāo)示，并且ClassLoader負(fù)責(zé)class文件的加載等，至于它是否可以運(yùn)行，則由執(zhí)行引擎（Execution Engine）決定。

運(yùn)行時(shí)數(shù)據(jù)區(qū)

棧管理運(yùn)行，堆管存儲(chǔ)。JVM調(diào)優(yōu)主要是優(yōu)化Java堆和方法取

方法區(qū)（Method Area）

方法區(qū)是各線程共享的內(nèi)存區(qū)域，它用于存儲(chǔ)已被JVM加載的類信息、常量、靜態(tài)變量、運(yùn)行時(shí)常量池等數(shù)據(jù)。

1. 運(yùn)行時(shí)常量池
   運(yùn)行時(shí)常量池是方法區(qū)的一部分，用于存放編譯器生成的各種字面量和符號(hào)引用，這部分內(nèi)容將在類加載后存放到方法區(qū)的運(yùn)行時(shí)常量池中。相較于Class文件常量池，運(yùn)行時(shí)常量池更具動(dòng)態(tài)性，在運(yùn)行期間也可以將新的變量放入常量池中，而不是一定要在編譯時(shí)確定的常量才能放入。最主要的運(yùn)用便是String類的intern()方法。

Java堆(Java Heap)

Java堆是各線程共享的內(nèi)存區(qū)域，在JVM啟動(dòng)時(shí)創(chuàng)建，這塊區(qū)域是JVM中最大的， 用于存儲(chǔ)應(yīng)用的對(duì)象和數(shù)組，也是GC主要的回收區(qū)，一個(gè) JVM 實(shí)例只存在一個(gè)堆內(nèi)存，堆內(nèi)存的大小是可以調(diào)節(jié)的。類加載器讀取了類文件后，需要把類、方法、常變量放到堆內(nèi)存中，以方便執(zhí)行器執(zhí)行，堆內(nèi)存分為三部分：新生代、老年代、永久代。

PS：

• Jdk1.6及之前：常量池分配在永久代 。
• Jdk1.7：有，但已經(jīng)逐步“去永久代” 。
• Jdk1.8及之后：無永久代，改用元空間代替(java.lang.OutOfMemoryError: PermGen space,這種錯(cuò)誤將不會(huì)出現(xiàn)在JDK1.8中)。

Java棧(JVM Stack)

1. 棧是什么
   Java棧是線程私有的，是在線程創(chuàng)建時(shí)創(chuàng)建，它的生命期是跟隨線程的生命期，線程結(jié)束棧內(nèi)存也就釋放，對(duì)于棧來說不存在垃圾回收問題，只要線程一結(jié)束該棧就Over，生命周期和線程一致?；绢愋偷淖兞亢蛯?duì)象的引用變量都是在函數(shù)的棧內(nèi)存中分配。

2. 棧存儲(chǔ)什么
   每個(gè)方法執(zhí)行的時(shí)候都會(huì)創(chuàng)建一個(gè)棧幀，棧幀中主要存儲(chǔ)3類數(shù)據(jù)：

   • 局部變量表：輸入?yún)?shù)和輸出參數(shù)以及方法內(nèi)的變量；
   • 操作棧：記錄出棧和入棧的操作；
   • 棧幀數(shù)據(jù)：包括類文件、方法等等

3. 棧運(yùn)行原理
   棧中的數(shù)據(jù)都是以棧幀的格式存在，棧幀是一個(gè)內(nèi)存區(qū)塊，是一個(gè)數(shù)據(jù)集，是一個(gè)有關(guān)方法和運(yùn)行期數(shù)據(jù)的數(shù)據(jù)集。每一個(gè)方法被調(diào)用直至執(zhí)行完成的過程，就對(duì)應(yīng)著一個(gè)棧幀在棧中從入棧到出棧的過程。

4. 本地方法棧(Native Method Stack)
   本地方法棧和JVM棧發(fā)揮的作用非常相似，也是線程私有的，區(qū)別是JVM棧為JVM執(zhí)行Java方法（也就是字節(jié)碼）服務(wù)，而本地方法棧為JVM使用到的Native方法服務(wù)。它的具體做法是在本地方法棧中登記native方法，在執(zhí)行引擎執(zhí)行時(shí)加載Native Liberies.有的虛擬機(jī)（比如Sun Hotpot）直接把兩者合二為一。

程序計(jì)數(shù)器(Program Counter Register)

程序計(jì)數(shù)器是一塊非常小的內(nèi)存空間，幾乎可以忽略不計(jì)，每個(gè)線程都有一個(gè)程序計(jì)算器，是線程私有的，可以看作是當(dāng)前線程所執(zhí)行的字節(jié)碼的行號(hào)指示器，指向方法區(qū)中的方法字節(jié)碼（下一個(gè)將要執(zhí)行的指令代碼），由執(zhí)行引擎讀取下一條指令。

執(zhí)行引擎(Execution Engine)

執(zhí)行引擎執(zhí)行包在裝載類的方法中的指令，也就是方法。執(zhí)行引擎以指令為單位讀取Java字節(jié)碼。它就像一個(gè)CPU一樣，一條一條地執(zhí)行機(jī)器指令。每個(gè)字節(jié)碼指令都由一個(gè)1字節(jié)的操作碼和附加的操作數(shù)組成。執(zhí)行引擎取得一個(gè)操作碼，然后根據(jù)操作數(shù)來執(zhí)行任務(wù)，完成后就繼續(xù)執(zhí)行下一條操作碼。

不過Java字節(jié)碼是用一種人類可以讀懂的語言編寫的，而不是用機(jī)器可以直接執(zhí)行的語言。因此，執(zhí)行引擎必須把字節(jié)碼轉(zhuǎn)換成可以直接被JVM執(zhí)行的語言。字節(jié)碼可以通過以下兩種方式轉(zhuǎn)換成合適的語言：

• 解釋器： 一條一條地讀取，解釋并執(zhí)行字節(jié)碼執(zhí)行，所以它可以很快地解釋字節(jié)碼，但是執(zhí)行起來會(huì)比較慢。這是解釋執(zhí)行語言的一個(gè)缺點(diǎn)。

• 即時(shí)編譯器：用來彌補(bǔ)解釋器的缺點(diǎn)，執(zhí)行引擎首先按照解釋執(zhí)行的方式來執(zhí)行，然后在合適的時(shí)候，即時(shí)編譯器把整段字節(jié)碼編譯成本地代碼。然后，執(zhí)行引擎就沒有必要再去解釋執(zhí)行方法了，它可以直接通過本地代碼去執(zhí)行。執(zhí)行本地代碼比一條一條進(jìn)行解釋執(zhí)行的速度快很多，編譯后的代碼可以執(zhí)行的很快，因?yàn)楸镜卮a是保存在緩存里的。

垃圾收集(Garbage Collection, GC)

垃圾收集即垃圾回收，簡(jiǎn)單的說垃圾回收就是回收內(nèi)存中不再使用的對(duì)象。所謂使用中的對(duì)象（已引用對(duì)象），指的是程序中有指針指向的對(duì)象；而未使用中的對(duì)象（未引用對(duì)象），則沒有被任何指針給指向，因此占用的內(nèi)存也可以被回收掉。

垃圾回收的基本步驟

• 查找內(nèi)存中不在使用的對(duì)象（GC判斷策略）
• 釋放這些對(duì)象占用的內(nèi)存（GC收集方法）

GC判斷策略

1. 引用計(jì)數(shù)算法（早期策略）
   引用計(jì)數(shù)算法是給對(duì)象添加一個(gè)引用計(jì)數(shù)器，每當(dāng)有一個(gè)引用它時(shí)，計(jì)數(shù)器值就加1；當(dāng)引用失效時(shí)，計(jì)數(shù)器值就減1；任何時(shí)刻計(jì)數(shù)器都為0的對(duì)象就是不可能再被使用的對(duì)象。
   優(yōu)點(diǎn)：引用計(jì)數(shù)收集器可以很快的執(zhí)行，交織在程序運(yùn)行中。對(duì)程序需要不被長(zhǎng)時(shí)間打斷的實(shí)時(shí)環(huán)境比較有利。
   缺點(diǎn)：很難解決對(duì)象之間相互循環(huán)引用的問題。如父對(duì)象有一個(gè)對(duì)子對(duì)象的引用，子對(duì)象反過來引用父對(duì)象。這樣，他們的引用計(jì)數(shù)永遠(yuǎn)不可能為0。

2. 根搜索算法（可達(dá)性分析算法）
   根搜索算法是從離散數(shù)學(xué)中的圖論引入的，程序把所有的引用關(guān)系看作一張圖，基本思路就是通過一系列名為“GC Roots”的對(duì)象作為起始點(diǎn)，從這些節(jié)點(diǎn)開始向下搜索，搜索所走過的路徑稱為引用鏈（Reference Chain），當(dāng)一個(gè)對(duì)象到GC Roots沒有任何引用鏈相連（也就是說從GC Roots到這個(gè)對(duì)象不可達(dá)）時(shí)，則證明此對(duì)象是無用的，可回收的。

在Java語言里，可作為GC Roots的對(duì)象包括以下幾種：

• 虛擬機(jī)棧（棧幀中的局部變量表）中引用的對(duì)象；
• 方法區(qū)中類靜態(tài)屬性引用的對(duì)象；
• 方法區(qū)中常量引用的對(duì)象；
• 本地方法棧中JNI（Native方法）引用的對(duì)象。

注：在根搜索算法中不可達(dá)的對(duì)象，也并非是“非死不可”的，因?yàn)橐嬲嬉粋€(gè)對(duì)象死亡，至少要經(jīng)歷兩次標(biāo)記過程：

1. 是標(biāo)記沒有與GC Roots相連接的引用鏈；

2. 是GC對(duì)在F-Queue執(zhí)行隊(duì)列中的對(duì)象進(jìn)行的小規(guī)模標(biāo)記，篩選的條件是此對(duì)象是否有必要執(zhí)行finalize()方法。在finalize()方法中沒有重新與引用鏈建立關(guān)聯(lián)關(guān)系的，將被第二次標(biāo)記。

第二次標(biāo)記成功的對(duì)象將真的會(huì)被回收，如果對(duì)象在finalize()方法中重新與引用鏈建立了關(guān)聯(lián)關(guān)系，那么將會(huì)逃離本次回收

GC收集策略

1. 標(biāo)記-清除算法（Mark-Sweep）
   標(biāo)記-清除算法采用從根集合（GC Roots）進(jìn)行掃描，首先標(biāo)記出所有需要回收的對(duì)象（根搜索算法），標(biāo)記完成后統(tǒng)一回收掉所有被標(biāo)記的對(duì)象。

該算法有兩個(gè)問題：

• 效率問題：標(biāo)記和清除過程的效率都不高；
• 空間問題：標(biāo)記清除后會(huì)產(chǎn)生大量不連續(xù)的內(nèi)存碎片, 空間碎片太多可能會(huì)導(dǎo)致在運(yùn)行過程中需要分配較大對(duì)象時(shí)無法找到足夠的連續(xù)內(nèi)存而不得不提前觸發(fā)另一次垃圾收集。

2. 復(fù)制算法
   復(fù)制算法的提出是為了克服句柄的開銷和解決內(nèi)存碎片的問題。復(fù)制算法是將可用內(nèi)存按容量劃分為大小相等的兩塊, 每次只用其中一塊, 當(dāng)這一塊的內(nèi)存用完, 就將還存活的對(duì)象復(fù)制到另外一塊上面, 然后把已使用過的內(nèi)存空間一次清理掉。

3. 標(biāo)記-整理算法
   標(biāo)記整理算法的標(biāo)記過程與標(biāo)記清除算法相同, 但后續(xù)步驟不再對(duì)可回收對(duì)象直接清理, 而是讓所有存活的對(duì)象都向一端移動(dòng),然后清理掉端邊界以外的內(nèi)存。標(biāo)記-整理算法是在標(biāo)記-清除算法的基礎(chǔ)上，又進(jìn)行了對(duì)象的移動(dòng)，因此成本更高，但是卻解決了內(nèi)存碎片的問題。

4. 分代收集算法（Generational Collection）
   分代收集算法是目前大部分JVM的垃圾收集器采用的算法。它的核心思想是根據(jù)對(duì)象存活的生命周期將內(nèi)存劃分為若干個(gè)不同的區(qū)域。一般情況下將堆區(qū)劃分為老年代（Tenured Generation）和新生代（Young Generation），在堆區(qū)之外還有一個(gè)代就是永久代（Permanet Generation）。老年代的特點(diǎn)是每次垃圾收集時(shí)只有少量對(duì)象需要被回收，而新生代的特點(diǎn)是每次垃圾回收時(shí)都有大量的對(duì)象需要被回收，那么就可以根據(jù)不同代的特點(diǎn)采取最適合的收集算法。

新生代（Young Generation）的回收算法（以復(fù)制算法為主）

• 所有新生成的對(duì)象首先都是放在年輕代的。年輕代的目標(biāo)就是盡可能快速的收集掉那些生命周期短的對(duì)象。

• 新生代內(nèi)存按照8:1:1的比例分為一個(gè)eden區(qū)和兩個(gè)survivor(survivor0,survivor1)區(qū)。一個(gè)Eden區(qū)，兩個(gè) Survivor區(qū)(一般而言)。大部分對(duì)象在Eden區(qū)中生成?；厥諘r(shí)先將eden區(qū)存活對(duì)象復(fù)制到一個(gè)survivor0區(qū)，然后清空eden區(qū)，當(dāng)這個(gè)survivor0區(qū)也存放滿了時(shí)，則將eden區(qū)和survivor0區(qū)存活對(duì)象復(fù)制到另一個(gè)survivor1區(qū)，然后清空eden和這個(gè)survivor0區(qū)，此時(shí)survivor0區(qū)是空的，然后將survivor0區(qū)和survivor1區(qū)交換，即保持survivor1區(qū)為空， 如此往復(fù)。

• 當(dāng)survivor1區(qū)不足以存放 eden和survivor0的存活對(duì)象時(shí)，就將存活對(duì)象直接存放到老年代。若是老年代也滿了就會(huì)觸發(fā)一次Full GC(Major GC)，也就是新生代、老年代都進(jìn)行回收。

• 新生代發(fā)生的GC也叫做Minor GC，MinorGC發(fā)生頻率比較高(不一定等Eden區(qū)滿了才觸發(fā))。

老年代（Tenured Generation）的回收算法（以標(biāo)記-清除、標(biāo)記-整理為主）

• 在年輕代中經(jīng)歷了N次垃圾回收后仍然存活的對(duì)象，就會(huì)被放到老年代中。因此，可以認(rèn)為老年代中存放的都是一些生命周期較長(zhǎng)的對(duì)象。
• 內(nèi)存比新生代也大很多(大概比例是1:2)，當(dāng)老年代內(nèi)存滿時(shí)觸發(fā)Major GC即Full GC，F(xiàn)ull GC發(fā)生頻率比較低，老年代對(duì)象存活時(shí)間比較長(zhǎng)，存活率標(biāo)記高。

永久代（Permanet Generation）的回收算法
用于存放靜態(tài)文件，如Java類、方法等。永久代對(duì)垃圾回收沒有顯著影響，但是有些應(yīng)用可能動(dòng)態(tài)生成或者調(diào)用一些class，例如Hibernate 等，在這種時(shí)候需要設(shè)置一個(gè)比較大的永久代空間來存放這些運(yùn)行過程中新增的類。

永久代也稱方法區(qū)。方法區(qū)主要回收的內(nèi)容有：廢棄常量和無用的類。對(duì)于廢棄常量也可通過根搜索算法來判斷，但是對(duì)于無用的類則需要同時(shí)滿足下面3個(gè)條件：

• 該類所有的實(shí)例都已經(jīng)被回收，也就是Java堆中不存在該類的任何實(shí)例；
• 加載該類的ClassLoader已經(jīng)被回收；
• 該類對(duì)應(yīng)的java.lang.Class對(duì)象沒有在任何地方被引用，無法在任何地方通過反射訪問該類的方法。

垃圾收集器

1. Serial收集器（復(fù)制算法）
   新生代單線程收集器，標(biāo)記和清理都是單線程，優(yōu)點(diǎn)是簡(jiǎn)單高效。是client級(jí)別默認(rèn)的GC方式，可以通過-XX:+UseSerialGC來強(qiáng)制指定。

2. Serial Old收集器(標(biāo)記-整理算法)
   老年代單線程收集器，Serial收集器的老年代版本。

3. ParNew收集器(停止-復(fù)制算法)
   新生代多線程收集器，其實(shí)就是Serial收集器的多線程版本,在多核CPU環(huán)境下有著比Serial更好的表現(xiàn)。

4. Parallel Scavenge收集器(停止-復(fù)制算法)
   新生代并行的多線程收集器，追求高吞吐量，高效利用CPU。吞吐量一般為99%， 吞吐量= 用戶線程時(shí)間/(用戶線程時(shí)間+GC線程時(shí)間)。適合后臺(tái)應(yīng)用等對(duì)交互相應(yīng)要求不高的場(chǎng)景。是server級(jí)別默認(rèn)采用的GC方式，可用-XX:+UseParallelGC來強(qiáng)制指定，用-XX:ParallelGCThreads=4來指定線程數(shù)。

5. Parallel Old收集器(停止-復(fù)制算法)
   老年代并行的多線程收集器，Parallel Scavenge收集器的老年代版本，并行收集器，吞吐量?jī)?yōu)先。

6. CMS(Concurrent Mark Sweep)收集器（標(biāo)記-清除算法）
   CMS收集器是一種以獲取最短回收停頓時(shí)間為目標(biāo)的收集器，CMS收集器是基于“標(biāo)記--清除”(Mark-Sweep)算法實(shí)現(xiàn)的，整個(gè)過程分為四個(gè)步驟：

   1. 初始標(biāo)記： 標(biāo)記GC Roots能直接關(guān)聯(lián)到的對(duì)象，速度很快；
   2. 并發(fā)標(biāo)記： 進(jìn)行GC Roots Tracing的過程；
   3. 重新標(biāo)記： 修正并發(fā)標(biāo)記期間因用戶程序繼續(xù)運(yùn)作而導(dǎo)致標(biāo)記產(chǎn)生變動(dòng)的那一部分對(duì)象的標(biāo)記記錄，這個(gè)階段的停頓時(shí)間一般會(huì)比初始標(biāo)記階段稍長(zhǎng)一些，但比并發(fā)標(biāo)記時(shí)間短；
   4. 并發(fā)清除： 整個(gè)過程中耗時(shí)最長(zhǎng)的并發(fā)標(biāo)記和并發(fā)清除過程收集器線程都可以與用戶線程一起工作，所以，從總體上來說，CMS收集器的內(nèi)存回收過程是與用戶線程一起并發(fā)執(zhí)行的。

優(yōu)點(diǎn)：并發(fā)收集、低停頓

缺點(diǎn)：對(duì)CPU資源非常敏感、無法處理浮動(dòng)垃圾、產(chǎn)生大量空間碎片。

7. G1(Garbage First)收集器（標(biāo)記-整理算法）
   G1是一款面向服務(wù)端應(yīng)用的垃圾收集器，是基于“標(biāo)記-整理”算法實(shí)現(xiàn)的，與其他GC收集器相比，G1具備如下特點(diǎn)：

• 并行與并發(fā)
• 分代收集
• 空間整合
• 可預(yù)測(cè)性的停頓

G1運(yùn)作步驟

• 初始標(biāo)記(stop the world事件，CPU停頓只處理垃圾)
• 并發(fā)標(biāo)記(與用戶線程并發(fā)執(zhí)行)
• 最終標(biāo)記(stop the world事件，CPU停頓處理垃圾)
• 篩選回收(stop the world事件，根據(jù)用戶期望的GC停頓時(shí)間回收)

垃圾收集結(jié)構(gòu)圖

GC是什么時(shí)候觸發(fā)的？

由于對(duì)象進(jìn)行了分代處理，因此垃圾回收區(qū)域、時(shí)間也不一樣。GC有兩種類型：Scavenge GC和Full GC。

Scavenge GC

一般情況下，當(dāng)新對(duì)象生成，并且在Eden申請(qǐng)空間失敗時(shí)，就會(huì)觸發(fā)Scavenge GC，對(duì)Eden區(qū)域進(jìn)行GC，清除非存活對(duì)象，并且把尚且存活的對(duì)象移動(dòng)到Survivor區(qū)。然后整理Survivor的兩個(gè)區(qū)。這種方式的GC是對(duì)年輕代的Eden區(qū)進(jìn)行，不會(huì)影響到年老代。因?yàn)榇蟛糠謱?duì)象都是從Eden區(qū)開始的，同時(shí)Eden區(qū)不會(huì)分配的很大，所以Eden區(qū)的GC會(huì)頻繁進(jìn)行。因而，一般在這里需要使用速度快、效率高的算法，使Eden去能盡快空閑出來。

Full GC

對(duì)整個(gè)堆進(jìn)行整理，包括Young、Tenured和Perm。Full GC因?yàn)樾枰獙?duì)整個(gè)堆進(jìn)行回收，所以比Scavenge GC要慢，因此應(yīng)該盡可能減少Full GC的次數(shù)。在對(duì)JVM調(diào)優(yōu)的過程中，很大一部分工作就是對(duì)于Full GC的調(diào)節(jié)。

有如下原因可能導(dǎo)致Full GC：

1. 老年代（Tenured）被寫滿；
2. 永久代（Perm），jDK1.8后叫元空間（MetaSpace）被寫滿
3. System.gc()被顯示調(diào)用
4. 上一次GC之后Heap的各域分配策略動(dòng)態(tài)變化

PS：本文整理自以下博客
Java虛擬機(jī)難？一文了解JVM
扒一扒JVM的垃圾回收機(jī)制
若有發(fā)現(xiàn)問題請(qǐng)致郵 caoyanglee92@gmail.com