jvm內存回收機制

Java垃圾回收概況

　　Java GC（Garbage Collection，垃圾搜集，垃圾回收）機制，是Java與C++/C的主要區分之1，作為Java開發者，1般不需要專門編寫內存回收和垃圾清算代 碼，對內存泄漏和溢出的問題，也不需要像C程序員那樣戰戰兢兢。這是由于在Java虛擬機中，存在自動內存管理和垃圾打掃機制。概括地說，該機制對 JVM（Java Virtual Machine）中的內存進行標記，并肯定哪些內存需要回收，根據1定的回收策略，自動的回收內存，永不停息（Nerver Stop）的保證JVM中的內存空間，放置出現內存泄漏和溢出問題。

　　關于JVM，需要說明1下的是，目前使用最多的Sun公司的JDK中，自從 1999年的JDK1.2開始直至現在仍在廣泛使用的JDK6，其中默許的虛擬機都是HotSpot。2009年，Oracle收購Sun，加上之前收購 的EBA公司，Oracle具有3大虛擬機中的兩個：JRockit和HotSpot，Oracle也表明了想要整合兩大虛擬機的意圖，但是目前在新發布 的JDK7中，默許的虛擬機依然是HotSpot，因此本文中默許介紹的虛擬機都是HotSpot，相干機制也主要是指HotSpot的GC機制。

　　Java GC機制主要完成3件事：肯定哪些內存需要回收，肯定甚么時候需要履行GC，如何履行GC。經過這么長時間的發展（事實上，在Java語言出現之前，就有 GC機制的存在，如Lisp語言），Java GC機制已日臻完善，幾近可以自動的為我們做絕大多數的事情。但是，如果我們從事較大型的利用軟件開發，曾出現過內存優化的需求，就一定要研究 Java GC機制。

　　學習Java GC機制，可以幫助我們在平常工作中排查各種內存溢出或泄漏問題，解決性能瓶頸，到達更高的并發量，寫出更高效的程序。

JAVA內存劃分

了解Java GC機制，必須先清楚在JVM中內存區域的劃分。在Java運行時的數據區里，由JVM管理的內存區域分為下圖幾個模塊：

其中：

1，程序計數器（Program Counter Register）：程序計數器是1個比較小的內存區域，用于唆使當前線程所履行的字節碼履行到了第幾行，可以理解為是當前線程的行號唆使器。字節碼解釋器在工作時，會通過改變這個計數器的值來取下1條語句指令。

　　每一個程序計數器只用來記錄1個線程的行號，所以它是線程私有（1個線程就有1個程序計數器）的。

　　如果程序履行的是1個Java方法，則計數器記錄的是正在履行的虛擬機字節碼指令地址；如果正在履行的是1個本地（native，由C語言編寫 完成）方法，則計數器的值為Undefined，由于程序計數器只是記錄當前指令地址，所以不存在內存溢出的情況，因此，程序計數器也是所有JVM內存區 域中唯逐一個沒有定義OutOfMemoryError的區域。

2，虛擬機棧（JVM Stack）：1個線程的每一個方法在履行的同時，都會創建1個棧幀（Statck Frame），棧幀中存儲的有局部變量表、操作站、動態鏈接、方法出口等，當方法被調用時，棧幀在JVM棧中入棧，當方法履行完成時，棧幀出棧。

　　局部變量表中存儲著方法的相干局部變量，包括各種基本數據類型，對象的援用，返回地址等。在局部變量表中，只有long和double類型會占 用2個局部變量空間（Slot，對32位機器，1個Slot就是32個bit），其它都是1個Slot。需要注意的是，局部變量表是在編譯時就已肯定 好的，方法運行所需要分配的空間在棧幀中是完全肯定的，在方法的生命周期內都不會改變。

　　虛擬機棧中定義了兩種異常，如果線程調用的棧深度大于虛擬機允許的最大深度，則拋出StatckOverFlowError（棧溢出）；不過量 數Java虛擬機都允許動態擴大虛擬機棧的大小(有少部份是固定長度的)，所以線程可以1直申請棧，知道內存不足，此時，會拋出 OutOfMemoryError（內存溢出）。

　　每一個線程對應著1個虛擬機棧，因此虛擬機棧也是線程私有的。

3，本地方法棧（Native Method Statck）：本地方法棧在作用，運行機制，異常類型等方面都與虛擬機棧相同，唯1的區分是：虛擬機棧是履行Java方法的，而本地方法棧是用來履行native方法的，在很多虛擬機中（如Sun的JDK默許的HotSpot虛擬機），會將本地方法棧與虛擬機棧放在1起使用。

　　本地方法棧也是線程私有的。

4，堆區（Heap）：堆區是理解Java GC機制最重要的區域，沒有之1。在JVM所管理的內存中，堆區是最大的1塊，堆區也是Java GC機制所管理的主要內存區域，堆區由所有線程同享，在虛擬機啟動時創建。堆區的存在是為了存儲對象實例，原則上講，所有的對象都在堆區上分配內存（不過現代技術里，也不是這么絕對的，也有棧上直接分配的）。

　　1般的，根據Java虛擬機規范規定，堆內存需要在邏輯上是連續的（在物理上不需要），在實現時，可以是固定大小的，也能夠是可擴大的，目前主 流的虛擬機都是可擴大的。如果在履行垃圾回收以后，仍沒有足夠的內存分配，也不能再擴大，將會拋出OutOfMemoryError:Java heap space異常。

　　關于堆區的內容還有很多，將在下節“Java內存分配機制”中詳細介紹。

5，方法區（Method Area）：在Java虛擬機規范中，將方法區作為堆的1個邏輯部份來對待，但事實 上，方法區其實不是堆（Non-Heap）；方法區是各個線程同享的區域，用于存儲已被虛擬機加載的類信息（即加載類時需要加載的信息，包括版本、field、方法、接口等信息）、final常量、靜態變量、編譯器即時編譯的代碼等。

　　方法區在物理上也不需要是連續的，可以選擇固定大小或可擴大大小，并且方法區比堆還多了1個限制：可以選擇是不是履行垃圾搜集。1般的，方法區上 履行的垃圾搜集是很少的，這也是方法區被稱為永久代的緣由之1（HotSpot），但這也不代表著在方法區上完全沒有垃圾搜集，其上的垃圾搜集主要是針對 常量池的內存回收和對已加載類的卸載。

　　在方法區上進行垃圾搜集，條件刻薄而且相當困難，效果也不使人滿意，所以1般不做太多斟酌，可以留作以落后1步深入研究時使用。

　　在方法區上定義了OutOfMemoryError:PermGen space異常，在內存不足時拋出。

　　運行經常量池（Runtime Constant Pool）是方法區的1部份，用于存儲編譯期就生成的字面常量、符號援用、翻譯出來的直接援用（符號援用就是編碼是用字符串表示某個變量、接口的位置，直接援用就是根據符號援用翻譯出來的地址，將在類鏈接階段完成翻譯）；運行經常量池除存儲編譯期常量外，也能夠存儲在運行時間產生的常量（比如String類的intern()方法，作用是String保護了1個常量池，如果調用的字符“abc”已在常量池中，則返回池中的字符串地址，否則，新建1個常量加入池中，并返回地址）。

6，直接內存（Direct Memory）：直接內存其實不是JVM管理的內存，可以這樣理解，直接內存，就是 JVM之外的機器內存，比如，你有4G的內存，JVM占用了1G，則其余的3G就是直接內存，JDK中有1種基于通道（Channel）和緩沖區 （Buffer）的內存分配方式，將由C語言實現的native函數庫分配在直接內存中，用存儲在JVM堆中的DirectByteBuffer來援用。 由于直接內存收到本機器內存的限制，所以也可能出現OutOfMemoryError的異常。

Java內存分配機制

這里所說的內存分配，主要指的是在堆上的分配，1般的，對象的內存分配都是在堆上進行，但現代技術也支持將對象拆成標量類型（標量類型即原子類型，表示單個值，可以是基本類型或String等），然后在棧上分配，在棧上分配的很少見，我們這里不斟酌。

　　Java內存分配和回收的機制概括的說，就是：分代分配，分代回收。對象將根據存活的時間被分為：年輕代（Young Generation）、年老代（Old Generation）、永久代（Permanent Generation，也就是方法區）。以下圖（來源于《成為JavaGC專家part I》，http://www.importnew.com/1993.html）：

　　年輕代（Young Generation）：對象被創建時，內存的分配首先產生在年輕代（大對象可以直接 被創建在年老代），大部份的對象在創建后很快就不再使用，因此很快變得不可達，因而被年輕代的GC機制清算掉（IBM的研究表明，98%的對象都是很快消 亡的），這個GC機制被稱為Minor GC或叫Young GC。注意，Minor GC其實不代表年輕代內存不足，它事實上只表示在Eden區上的GC。

　　年輕代上的內存分配是這樣的，年輕代可以分為3個區域：Eden區（伊甸園，亞當和夏娃偷吃禁果生娃娃的地方，用來表示內存首次分配的區域，再 貼切不過）和兩個存活區（Survivor 0 、Survivor 1）。內存分配進程為（來源于《成為JavaGC專家part I》，http://www.importnew.com/1993.html）：

　　從上面的進程可以看出，Eden區是連續的空間，且Survivor總有1個為空。經過1次GC和復制，1個Survivor中保存著當前還活 著的對象，而Eden區和另外一個Survivor區的內容都不再需要了，可以直接清空，到下1次GC時，兩個Survivor的角色再互換。因此，這類方 式分配內存和清算內存的效力都極高，這類垃圾回收的方式就是著名的“停止-復制（Stop-and-copy）”清算法（將Eden區和1個Survivor中依然存活的對象拷貝到另外一個Survivor中），這不代表著停止復制清算法很高效，其實，它也只在這類情況下高效，如果在老年代采取停止復制，則挺悲劇的。

　　在Eden區，HotSpot虛擬機使用了兩種技術來加快內存分配。分別是bump-the-pointer和TLAB（Thread- Local Allocation Buffers），這兩種技術的做法分別是：由于Eden區是連續的，因此bump-the-pointer技術的核心就是跟蹤最后創建的1個對象，在對 象創建時，只需要檢查最后1個對象后面是不是有足夠的內存便可，從而大大加快內存分配速度；而對TLAB技術是對多線程而言的，將Eden辨別為若干 段，每一個線程使用獨立的1段，避免相互影響。TLAB結合bump-the-pointer技術，將保證每一個線程都使用Eden區的1段，并快速的分配內 存。

　　年老代（Old Generation）：對象如果在年輕代存活了足夠長的時間而沒有被清算掉（即在幾次 Young GC后存活了下來），則會被復制到年老代，年老代的空間1般比年輕代大，能寄存更多的對象，在年老代上產生的GC次數也比年輕代少。當年老代內存不足時， 將履行Major GC，也叫 Full GC。　　

　　可能存在年老代對象援用新生代對象的情況，如果需要履行Young GC，則可能需要查詢全部老年代以肯定是不是可以清算回收，這明顯是低效的。解決的方法是，年老代中保護1個512 byte的塊——”card table“，所有老年代對象援用新生代對象的記錄都記錄在這里。Young GC時，只要查這里便可，不用再去查全部老年代，因此性能大大提高。

JVM經常使用內存參數設置

a: -Xmx<n> 

Java對象的訪問方式

1般來講，1個Java的援用訪問觸及到3個內存區域：JVM棧，堆，方法區。

　　以最簡單的本地變量援用：Object obj = new Object()為例：

• Object obj表示1個本地援用，存儲在JVM棧的本地變量表中，表示1個reference類型數據；
• new Object()作為實例對象數據存儲在堆中；
• 堆中還記錄了Object類的類型信息（接口、方法、field、對象類型等）的地址，這些地址所履行的數據存儲在方法區中；

在Java虛擬機規范中，對通過reference類型援用訪問具體對象的方式并未做規定，目前主流的實現方式主要有兩種：

1，通過句柄訪問（圖來自于《深入理解Java虛擬機：JVM高級殊效與最好實現》）：

通過句柄訪問的實現方式中，JVM堆中會專門有1塊區域用來作為句柄池，存儲相干句柄所履行的實例數據地址（包括在堆中地址和在方法區中的地址）。這類實現方法由于用句柄表示地址，因此10分穩定。

2，通過直接指針訪問：（圖來自于《深入理解Java虛擬機：JVM高級殊效與最好實現》）

通過直接指針訪問的方式中，reference中存儲的就是對象在堆中的實際地址，在堆中存儲的對象信息中包括了在方法區中的相應類型數據。這類方法最大的優勢是速度快，在HotSpot虛擬機中用的就是這類方式。

如何肯定某個對象是垃圾？

在這1小節我們先了解1個最基本的問題：如果肯定某個對象是“垃圾”？既然垃圾搜集器的任務是回收垃圾對象所占的空間供新的對象使用，那末垃圾搜集器如何肯定某個對象是“垃圾”？—即通過甚么方法判斷1個對象可以被回收了。

　　在java中是通過援用來和對象進行關聯的，也就是說如果要操作對象，必須通過援用來進行。那末很明顯1個簡單的辦法就是通過援用計數來判斷1個對象是不是可以被回收。不失1般性，如果1個對象沒有任何援用與之關聯，則說明該對象基本不太可能在其他地方被使用到，那末這個對象就成為可被回收的對象了。這類方式成為援用計數法。這類方式的特點是實現簡單，而且效力較高，但是它沒法解決循環援用的問題，因此在Java中并沒有采取這類方式（Python采取的是援用計數法）。

為了解決這個問題，在Java中采取了 可達性分析法。該方法的基本思想是通過1系列的“GC Roots”對象作為出發點進行搜索，如果在“GC Roots”和1個對象之間沒有可達路徑，則稱該對象是不可達的，不過要注意的是被判定為不可達的對象不1定就會成為可回收對象。被判定為不可達的對象要成為可回收對象必須最少經歷兩次標記進程，如果在這兩次標記進程中依然沒有逃脫成為可回收對象的可能性，則基本上就真的成為可回收對象了。

在肯定了哪些垃圾可以被回收后，垃圾搜集器要做的事情就是開始進行垃圾回收，但是這里面觸及到1個問題是：如何高效地進行垃圾回收。由于Java虛擬機規范并沒有對如何實現垃圾搜集器做出明確的規定，因此各個廠商的虛擬機可以采取不同的方式來實現垃圾搜集器，所以在此只討論幾種常見的垃圾搜集算法的核心思想。

　　1.Mark-Sweep（標記-清除）算法

　　這是最基礎的垃圾回收算法，之所以說它是最基礎的是由于它最容易實現，思想也是最簡單的。標記-清除算法分為兩個階段：標記階段和清除階段。標記階段的任務是標記出所有需要被回收的對象，清除階段就是回收被標記的對象所占用的空間。具體進程以下圖所示：

　　從圖中可以很容易看出標記-清除算法實現起來比較容易，但是有1個比較嚴重的問題就是容易產生內存碎片，碎片太多可能會致使后續進程中需要為大對象分配空間時沒法找到足夠的空間而提早觸發新的1次垃圾搜集動作。

　　2.Copying（復制）算法

　　為了解決Mark-Sweep算法的缺點，Copying算法就被提了出來。它將可用內存按容量劃分為大小相等的兩塊，每次只使用其中的1塊。當這1塊的內存用完了，就將還存活著的對象復制到另外1塊上面，然后再把已使用的內存空間1次清算掉，這樣1來就不容易出現內存碎片的問題。具體進程以下圖所示：

　　這類算法雖然實現簡單，運行高效且不容易產生內存碎片，但是卻對內存空間的使用做出了高昂的代價，由于能夠使用的內存縮減到原來的1半。

　　很明顯，Copying算法的效力跟存活對象的數目多少有很大的關系，如果存活對象很多，那末Copying算法的效力將會大大下降。

　　3.Mark-Compact（標記-整理）算法

　　為了解決Copying算法的缺點，充分利用內存空間，提出了Mark-Compact算法。該算法標記階段和Mark-Sweep1樣，但是在完成標記以后，它不是直接清算可回收對象，而是將存活對象都向1端移動，然后清算掉端邊界之外的內存。具體進程以下圖所示：

　　4.Generational Collection（分代搜集）算法

　　分代搜集算法是目前大部份JVM的垃圾搜集器采取的算法。它的核心思想是根據對象存活的生命周期將內存劃分為若干個不同的區域。1般情況下將堆區劃分為老年代（Tenured Generation）和新生代（Young Generation），老年代的特點是每次垃圾搜集時只有少許對象需要被回收，而新生代的特點是每次垃圾回收時都有大量的對象需要被回收，那末就能夠根據不同代的特點采取最合適的搜集算法。

　　目前大部份垃圾搜集器對新生代都采取Copying算法，由于新生代中每次垃圾回收都要回收大部份對象，也就是說需要復制的操作次數較少，但是實際中其實不是依照1：1的比例來劃分新生代的空間的，1般來講是將新生代劃分為1塊較大的Eden空間和兩塊較小的Survivor空間，每次使用Eden空間和其中的1塊Survivor空間，當進行回收時，將Eden和Survivor中還存活的對象復制到另外一塊Survivor空間中，然后清算掉Eden和剛才使用過的Survivor空間。

　　而由于老年代的特點是每次回收都只回收少許對象，1般使用的是Mark-Compact算法。

　　注意，在堆區以外還有1個代就是永久代（Permanet Generation），它用來存儲class類、常量、方法描寫等。對永久代的回收主要回收兩部份內容：廢棄常量和無用的類。

Java 中的堆也是 GC 搜集垃圾的主要區域。GC 分為兩種：Minor GC、Full GC ( 或稱為 Major GC )。 

年輕代：

Minor GC 是產生在新生代中的垃圾搜集動作，所采取的是復制算法。 
新生代幾近是所有 Java 對象誕生的地方，即 Java 對象申請的內存和寄存都是在這個地方。Java 中的大部份對象通常不需久長存活，具有朝生夕滅的性質。當1個對象被判定為 “死亡” 的時候，GC 就有責任來回收掉這部份對象的內存空間。新生代是 GC 搜集垃圾的頻繁區域。

當對象在 Eden ( 包括1個 Survivor 區域，這里假定是 from 區域 ) 誕生后，在經過1次 Minor GC 后，如果對象還存活，并且能夠被另外1塊 Survivor 區域所容納( 上面已假定為 from 區域，這里應為 to 區域，即 to 區域有足夠的內存空間來存儲 Eden 和 from 區域中存活的對象 )，則使用復制算法將這些依然還存活的對象復制到另外1塊 Survivor 區域 ( 即 to 區域 ) 中，然后清算所使用過的 Eden 和 Survivor 區域 ( 即 from 區域 )，并且將這些對象的年齡設置為1，以后對象在 Survivor 區每熬過1次 Minor GC，就將對象的年齡 + 1，當對象的年齡到達某個值時 ( 默許是 15 歲，可以通過參數 -XX:MaxTenuringThreshold 來設定 )，這些對象就會成為老年代。但這也不是1定的，對1些較大的對象 ( 即需要分配1塊較大的連續內存空間 ) 則是直接進入到老年代。

老年代：

Full GC 是產生在老年代的垃圾搜集動作，所采取的是標記-清除-整理算法。現實的生活中，老年代的人通常會比新生代的人 “早死”。堆內存中的老年代(Old)不同于個，老年代里面的對象幾近個個都是在 Survivor 區域中熬過來的，它們是不會那末容易就 “死掉” 了的。因此，Full GC 產生的次數不會有 Minor GC 那末頻繁，并且做1次 Full GC 要比進行1次 Minor GC 的時間更長。另外，標記-清除算法搜集垃圾的時候會產生許多的內存碎片 ( 即不連續的內存空間 )，爾后需要為較大的對象分配內存空間時，若沒法找到足夠的連續的內存空間，就會提早觸發1次 GC 的搜集動作。

方法區（永久代）：

典型的垃圾搜集器

垃圾搜集算法是 內存回收的理論基礎，而垃圾搜集器就是內存回收的具體實現。下面介紹1下HotSpot（JDK 7)虛擬機提供的幾種垃圾搜集器，用戶可以根據自己的需求組合出各個年代使用的搜集器。

　　1.Serial/Serial Old

　　Serial/Serial Old搜集器是最基本最古老的搜集器，它是1個單線程搜集器，并且在它進行垃圾搜集時，必須暫停所有用戶線程。Serial搜集器是針對新生代的搜集器，采取的是Copying算法，Serial Old搜集器是針對老年代的搜集器，采取的是Mark-Compact算法。它的優點是實現簡單高效，但是缺點是會給用戶帶來停頓。

　　2.ParNew

　　ParNew搜集器是Serial搜集器的多線程版本，使用多個線程進行垃圾搜集。

　　3.Parallel Scavenge

　　Parallel Scavenge搜集器是1個新生代的多線程搜集器（并行搜集器），它在回收期間不需要暫停其他用戶線程，其采取的是Copying算法，該搜集器與前兩個搜集器有所不同，它主要是為了到達1個可控的吞吐量。

　　4.Parallel Old

　　Parallel Old是Parallel Scavenge搜集器的老年代版本（并行搜集器），使用多線程和Mark-Compact算法。

　　5.CMS

　　CMS（Current Mark Sweep）搜集器是1種以獲得最短回收停頓時間為目標的搜集器，它是1種并發搜集器，采取的是Mark-Sweep算法。

　　6.G1

　　G1搜集器是現今搜集器技術發展最前沿的成果，它是1款面向服務端利用的搜集器，它能充分利用多CPU、多核環境。因此它是1款并行與并發搜集器，并且它能建立可預測的停頓時間模型。

生活不易，碼農辛苦
如果您覺得本網站對您的學習有所幫助,可以手機掃描二維碼進行捐贈