JVM 總結

JVM GC 總結，

周志明大大的《深入理解Java虛擬機》出第三版了，早早的買了這本書，卻一直沒有花時間看，近來抽空溫習了一下，感覺又有了新的識訓，這里簡單總結下，

GC的由來

由于堆的動態性，作業系統將堆交由給了開發者自己管理，手動申請，手動釋放，對于C++,則是將這個權限繼續交給了開發者，而對于Java，則是將這個程序自動化了，為什么要釋放記憶體呢？最簡單的原因就是作業系統一共給你了4G的記憶體空間，你需要的時候，就去借用，有借有還，再借不難，只借不還，最后4G記憶體空間被用完了，你就無法再申請新的記憶體了，記憶體泄漏，就是只借不還，

JVM在作業系統與開發者之間又封裝了一層，間接的接管了記憶體的劃分，同時也將堆統一管理起來，使得開發者只管借用記憶體，由JVM負責回收，了解JVM的回識訓制，明白它的原理，能讓開發者在不同的場景下，定制不同的回收規則，提高回收效率，

關于GC的思考

如果讓我設計一個能自動回收垃圾的虛擬機，我會怎么設計呢？

• 什么時候開始回收？
• 怎么判斷這部分記憶體可以回收？
• 怎么回收這部分的垃圾？

這3個問題，也是JVM開發者一直在思考的問題，之前簡單了解過JVM,就知道JVM會有Stop The World的問題，這對于用戶體驗來說非常不好，其根本原因便是因為在回收垃圾的時候，用戶執行緒可能會修改這部分記憶體，如果不暫停用戶執行緒，則可能會導致嚴重的問題，而如何減少Stop The World的時候，甚至讓其消失，是各個垃圾回收器一直追求的目標，

哪些記憶體可以回收？

對于一個物件來說，當不存在任何一個參考能夠訪問到這個物件的時候，則說明這個物件可以進行回收，因為沒有任何參考指向這個物件，那么這個物件就不能被讀或寫，

• 參考計數法

  前面說判斷一個物件可以被回收的標準就是是否還有參考指向這個物件，所以最容易想到的便是參考計數法，通過判斷一個物件的參考數量即可，可是這樣無法判斷兩個回圈參考的物件，

• 可達性分析

  可達性分析指的是從目前程式中正在使用的所有參考的物件出發，回圈遍歷所有能找到的物件，

  作為出發的點的這些物件，被稱為GC Roots

  GC Roots主要包括以下幾種：

  • 在虛擬機堆疊（比如堆疊幀中的本地遍歷表）中參考的物件
  • 靜態屬性參考的物件
  • 常量池參考物件（比如String Table）
  • 本地方法堆疊參考的物件
  • Java虛擬機內部的參考對應的物件
  • 所有被同步鎖持有的物件
  • ...

  總體來說，就是當前程式中正在被使用的參考所指向的物件會被作為GC Roots

  ---

從GC Roots出發，依次查找，就能標記出當前存活的物件，但是標記這個程序，細節上依然存在問題：

• STW : 標記是通過參考查找物件的，如果在標記程序中，用戶修改了參考的物件，那么會導致不可預估的后果，因此一般標記程序中，是會STW的

• 跨代標記 ： 現在的垃圾回收器，大多數都是分代，或者磁區域回收的，也就是說，可能進行垃圾回收的時候，不是標記所有的垃圾，而是標記一部分，比如老年代或者新生代，此時就存在一個問題，跨代參考，比如一個新生代的物件，僅僅被一個老年代物件參考的話，對于Yong GC來說，是不會掃描老年代物件的，這個時候就會造成誤判，解決這個誤判的方法便是記憶集（Remembered Set），記憶集通過AOP技術生成寫屏障來維護，

  前面說了從GC Roots開始掃面，那分代收集的，怎么知道哪些物件是新生代的，哪些物件是老年代的呢？因為GC Roots是包含了所有參考的，后面想想，其實物件的分代資訊是存放在物件頭里面的，在掃描GC Roots的時候，只保留新生代的物件即可，這樣基本能保證掃描到的是新生代物件，然后老年代對新生代參考交給記憶集實作就行（自己的猜測，沒有證據）

  JVM書中說道通過AOP生成的寫屏障會使得只要有更新操作，無論更新的是不是老年代對新生代物件的參考，都會使卡表變臟，不過這樣的代價相對來說是能接受的，

• GC Roots 需要掃描的參考過多 ：隨著現在Java應用越做越大，Java堆也越來越大，GC Roots的掃描是需要STW的，如果每次GC都逐個掃描，會非常的浪費時間，解決這個問題的辦法就是OopMap，使用OopMap記錄應用程式所存放的參考，每次需要GC的時候掃描這個OopMap即可生成對應的GC Roots，OopMap通過安全點和安全區域來維護，只有在安全點或安全區域的時候，才更新OopMap和進行垃圾回收，

• 并發標記程序可能丟失存活的物件 ：從CMS到G1，都將從GC Roots出發標記存活物件的程序修改成并發的，這樣會需要解決的問題就是標記程序中如果用戶修改了物件的參考，可能會導致本應該存活的物件”丟失“（可以通過三色標記分析）,相應的解決方案便是破壞存活物件消失的必要條件，分別是增量更新（Incremental Upate）和原始快照（Snapshot At The Begin,SATB）,增量更新破壞的是第一個條件，每插入一個參考，就都記錄下來，而原始快照破壞的是第二個條件，每洗掉一個，都將其記錄下來，

  增量更新和并發快照也是通過前面所說的AOP技術生成寫屏障來維護

  ---

通過以上分析以及解決方案，基本明白了怎么標記那些記憶體可以回收，接下來需要分析的就是什么時候開始回收

什么時候開始記憶體回收？

對于記憶體回收來說，開始也需要有一定的講究，理論上來說，隨時隨地都可以開始記憶體回收，但是如果回收時使用的記憶體過多，會導致GC時間程序，進而STW時間也會很長，如果回收過于頻繁，又會導致吞吐量下降，畢竟每次掃描GC Roots都回STW的，

同時，前面還說過，對于用戶執行緒來說，需要將用戶執行緒運行到安全點，更新對應的OopMap，才能開始垃圾回收，

因此，對應何時GC，有以下幾點分析：

• 對于新生代來說，一般新生代滿了(Eden + Survivor1)就會開始進行（Yong/Minor GC）

• 對于老年代來說，一般是老年代滿了了會開始Full/Major GC

  注意：這里的滿了，需要根據具體的回收器不同，來衡量真正的滿，對于沒有并發程序的GC,老年代滿一般指的是真正到達100%,已經無法分配記憶體了，對于有并發程序的GC，則需要預留出來空間給用戶執行緒在并發程序中同時申請記憶體，如果預留記憶體過小，則會使用非并發垃圾回收器進行Full GC

  CMS: -XX:CMSInitiatingOccupancyFraction 設定，默認92% (JDK 8)，表示當老年代垃圾占用到92%就開始老年代回收， JDK 9后便無法使用CMS

  G1: -XX:G1ReservePercent設定，默認為10,表示當整個Java堆使用到達90%，就開始回收，同時配合的引數還有-XX:InitiatingHeapOccupancyPercent=n，默認值為45，表示使用率到達45%就啟動標記周期，這里的GC是Mixed GC

  一般來說，只有CMS才有Major GC，其他老年代GC都會回收整個Java堆，也稱為Full GC

• 統計得到的Minor GC晉升到老年代的平均大小大于老年代剩余的空間，（JDK 6 之后已經洗掉了擔保規則）

• GC并發失敗（concurrent mode failure）: 情況如前面說的，并發標記程序中，又出現了新生代晉升的情況，但是此時老年代剩下的記憶體不足夠放下晉升的物件的時候，會生導致Full GC

  這里的Full GC和情況1中說到達預留空間的GC不一樣，情況1是正常進行的GC，而這個并發失敗卻是GC程序中出現了例外，一般需要切換到非并發GC，此時性能會大大下降

• 方法區區域被使用完畢：JDK 8之后將方法區從Perm Gen替換成了元空間，一般來說元空間大小理論上等于本地記憶體大小，不過元空間有一個默認初始值，到達默認初始值后，會通過Full GC擴大

  注意：G1只有Yong GC和Mixed GC，沒有Full GC的概念，也就是說如果需要回收方法區的話，只能退化為Serial GC進行Full GC

  CMS可以通過-XX:+CMSClassUnloadingEnabled設定并發回收方法區

• 最大連續空間裝不下大物件：對于CMS，基于標記-清除演算法來說，即使空間足夠，但是由于記憶體碎片，裝不下分配的大物件時，會進行一次Full GC,對于G1來說，當分配巨型物件的時候，如果在老年代無法找到連續的Humongous的時候，會進行Full GC

• 用戶執行System.gc(),可以通過-XX:+DisableExplicitGC屏蔽

• ...

怎么回收這些記憶體

最后一步便是怎么回收這些記憶體，怎么回收，書中介紹不多，總體來說有以下三種：

• 標記-清除(Mark-Sweep)：最原始的方法，實作簡單，不用移動物件，很容易做到不用Stop The Word，但是缺點也很致命，容易產生記憶體碎片，標記清除的速度一般，Mark階段與活物件的數量成正比，Sweep階段與整堆大小成正比，目前只有CMS使用這種回收方案
• 標記-復制(Mark-Copying)：基于標記-清除修改的垃圾回收演算法，需要移動物件， 前期標記，然后復制活下來的物件到另一個區域，再總體回收整塊區域，標記復制演算法對于新生代這種專門放朝生夕死的物件效率非常高，因為存活下來的物件少，所以Mark階段和Copying階段花費的時間都會比較少，幾乎所有的分代GC新生代都是使用的這種演算法
• 標記-整理(Mark-Compact): 基于標記-清除演算法修改的垃圾回收器，需要移動物件，前期標記，然后將所有物件移動到一起，再對剩余的區域進行回收，速度最慢，但是不會產生記憶體碎片，

對于新生代使用標記-復制演算法，是毋庸置疑的，但是對于老年代，使用標記清除還是標記整理，需要有一定的考量，因為使用標記-清除，不用移動物件，速度會相對來說比較快，但是由于存在記憶體碎片，無法使用指標碰撞的方式分配記憶體，而不得不使用“磁區空閑分配鏈表”來解決記憶體分配的問題，這樣會對在記憶體分配帶來一定的效率影響，而標記-整理演算法需要移動物件，特別是對于老年代這種大物件來說，移動這些物件將是一種極為負重的操作，但是標記-整理不會產生記憶體碎片，

因此，基于以上考慮，對于CMS這種側重回應速度，致力于減少STW時間的回收器來說，選擇了標記-清除演算法，但是由于記憶體分配是一個非常頻繁的操作，使用"磁區空閑分配鏈表”會降低整個垃圾回收器的吞吐量，因此，對于Parllel Scavenge這種注重回收吞吐的垃圾回收器來說，選擇了標記-整理演算法，當然，對于G1則是吞吐和回應速度都比較注重，權衡之下，選擇了標記-整理(全域)演算法，

GC的概念，到這里基本總結完畢，但是，如果僅僅是理論，只是讓我們記著一些概念性的東西，接下來，我會結合CMS，G1的GC日志以及《深入理解JVM》第四章的內容，聊一聊如何分析以及查看GC程序，簡單介紹如果進行GC調優，

個人公眾號：

不定期更新一些經典Java書籍總結，