Minor GC、Major GC、Full GC有什么區(qū)別

這篇文章主要講解了“Minor GC、Major GC、Full GC有什么區(qū)別”，文中的講解內(nèi)容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“Minor GC、Major GC、Full GC有什么區(qū)別”吧！

GC的引入

堆內(nèi)存劃分為Eden、Survivor（2）和Tenured/Old空間。

發(fā)生在年輕代的GC——Minor GC

其中Minor GC如下圖所示

• 虛擬機給每個對象定義一個對象年齡（Age）計數(shù)器。對象在Eden生并經(jīng)過第一次Minor GC后仍然存活，并且能被Survivor容納的話，將被移動到Survivor空間中，并將對象年齡設(shè)為 1。

• 對象在Survivor區(qū)中每熬過一次Minor GC，年齡就增加1歲，當它的年齡增加到一定程度（默認為15歲）時，就會被晉升到老年代中。

• 對象晉升老年代的年齡閾值，可以通過參數(shù)-XX:MaxTenuringThreshold來設(shè)置。

從年輕代空間（包括Eden和Survivor區(qū)域）回收內(nèi)存被稱為Minor GC。這一定義既清晰又易于理解，因為Java對象大多都具備朝生夕滅的特性，所以Minor GC非常頻繁，一般回收速度也比較快。

• JVM無法為一個新的對象分配空間時會觸發(fā)Minor GC，比如當Eden區(qū)滿了。所以分配率越高，越頻繁執(zhí)行Minor GC。

• 內(nèi)存池被填滿的時候，其中的內(nèi)容全部會被復(fù)制，指針會從0開始跟蹤空閑內(nèi)存。

• Eden和Survivor區(qū)進行了標記和復(fù)制操作，取代了經(jīng)典的標記、掃描、壓縮、清理操作。

• 所以Eden和Survivor區(qū)不存在內(nèi)存碎片，寫指針總是停留在所使用內(nèi)存池的頂部。

• 執(zhí)行Minor GC操作時，不會影響到方法區(qū)。從方法區(qū)到年輕代的引用被當成GCRoots，從年輕代到方法區(qū)的引用在標記階段被直接忽略掉。

• 質(zhì)疑常規(guī)的認知，所有的Minor GC都會觸發(fā) “全世界的暫停（stop-the-world）”，停止應(yīng)用程序的線程。對于大部分應(yīng)用程序，停頓導致的延遲都是可以忽略不計的。

• 其中的真相就是，大部分Eden區(qū)中的對象都能被認為是垃圾，永遠也不會被復(fù)制到Survivor區(qū)或者老年代空間。

• 如果正好相反，Eden區(qū)大部分新生對象不符合GC條件，Minor GC執(zhí)行時暫停的時間將會長很多。

Minor GC觸發(fā)機制：

當年輕代滿時就會觸發(fā)Minor GC，這里的年輕代滿指的是Eden代滿，Survivor滿不會引發(fā)GC。

發(fā)生在老年代的GC——Major GC/Full GC

• Major GC：主要是清理老年代：MajorGC的速度一般會比Minor GC慢 10倍以上

• Full GC：主要是清理整個堆空間—包括年輕代和老年代。

1. 首先，許多Major GC是由Minor GC觸發(fā)，所以很多情況下將這兩種GC分離是不太可能的。

2. 另一方面，許多現(xiàn)代垃圾收集機制會清理部分老年代空間，所以使用“cleaning”一詞只是部分正確。

這使得我們不用去關(guān)心到底是叫Major GC還是Full GC，大家應(yīng)該關(guān)注當前的GC是否停止了所有應(yīng)用程序的線程，還是能夠并發(fā)的處理而不用停掉應(yīng)用程序的線程。

老年代GC（Major GC/Full GC）：指發(fā)生在老年代的GC，出現(xiàn)了Major GC，經(jīng)常會伴隨至少一次的Minor GC（但非絕對的，ParallelScavenge收集器的收集策略里就有直接進行Major GC的策略選擇過程） 。

Full GC觸發(fā)機制：

• （1）調(diào)用System.gc時，系統(tǒng)建議執(zhí)行Full GC，但是不必然執(zhí)行

• （2）老年代空間不足

• （3）方法區(qū)空間不足：當永久代/元數(shù)據(jù)空間滿時也會引發(fā)Full GC，會導致Class、Method元信息的卸載。

• （4）通過Minor GC后進入老年代的平均大小大于老年代的可用內(nèi)存

• （5）由Eden區(qū)、survivor space1（From Space）區(qū)向survivor space2（To Space）區(qū)復(fù)制時，對象大小大于To Space可用內(nèi)存，則把該對象轉(zhuǎn)存到老年代，且老年代的可用內(nèi)存小于該對象大小

Full GC定義是相對明確的，就是針對整個新生代、老生代、元空間（metaspace，java8以上版本取代perm gen）的全局范圍的GC；

Minor GC和Major GC是俗稱，在Hotspot JVM實現(xiàn)的Serial GC, Parallel GC, CMS, G1 GC中大致可以對應(yīng)到某個Young GC和Old GC算法組合；

第一次嘗試通過 jstat 輸出：

my-precious: me$ jstat -gc -t 4235 1s

Time S0C    S1C    S0U    S1U      EC       EU        OC         OU       MC     MU    CCSC   CCSU   YGC     YGCT    FGC    FGCT     GCT   
 5.7 34048.0 34048.0  0.0   34048.0 272640.0 194699.7 1756416.0   181419.9  18304.0 17865.1 2688.0 2497.6      3    0.275   0      0.000    0.275
 6.7 34048.0 34048.0 34048.0  0.0   272640.0 247555.4 1756416.0   263447.9  18816.0 18123.3 2688.0 2523.1      4    0.359   0      0.000    0.359
 7.7 34048.0 34048.0  0.0   34048.0 272640.0 257729.3 1756416.0   345109.8  19072.0 18396.6 2688.0 2550.3      5    0.451   0      0.000    0.451
 8.7 34048.0 34048.0 34048.0 34048.0 272640.0 272640.0 1756416.0  444982.5  19456.0 18681.3 2816.0 2575.8      7    0.550   0      0.000    0.550
 9.7 34048.0 34048.0 34046.7  0.0   272640.0 16777.0  1756416.0   587906.3  20096.0 19235.1 2944.0 2631.8      8    0.720   0      0.000    0.720
10.7 34048.0 34048.0  0.0   34046.2 272640.0 80171.6  1756416.0   664913.4  20352.0 19495.9 2944.0 2657.4      9    0.810   0      0.000    0.810
11.7 34048.0 34048.0 34048.0  0.0   272640.0 129480.8 1756416.0   745100.2  20608.0 19704.5 2944.0 2678.4     10    0.896   0      0.000    0.896
12.7 34048.0 34048.0  0.0   34046.6 272640.0 164070.7 1756416.0   822073.7  20992.0 19937.1 3072.0 2702.8     11    0.978   0      0.000    0.978
13.7 34048.0 34048.0 34048.0  0.0   272640.0 211949.9 1756416.0   897364.4  21248.0 20179.6 3072.0 2728.1     12    1.087   1      0.004    1.091
14.7 34048.0 34048.0  0.0   34047.1 272640.0 245801.5 1756416.0   597362.6  21504.0 20390.6 3072.0 2750.3     13    1.183   2      0.050    1.233
15.7 34048.0 34048.0  0.0   34048.0 272640.0 21474.1  1756416.0   757347.0  22012.0 20792.0 3200.0 2791.0     15    1.336   2      0.050    1.386
16.7 34048.0 34048.0 34047.0  0.0   272640.0 48378.0  1756416.0   838594.4  22268.0 21003.5 3200.0 2813.2     16    1.433   2      0.050    1.484

這個片段是 JVM 啟動后第17秒提取的。基于該信息，我們可以得出這樣的結(jié)果，運行了12次 Minor GC、2次 Full GC，時間總跨度為50毫秒。

java -XX:+PrintGCDetails -XX:+UseConcMarkSweepGC eu.plumbr.demo.GarbageProducer

3.157: [GC (Allocation Failure) 3.157: [ParNew: 272640K->34048K(306688K), 0.0844702 secs] 272640K->69574K(2063104K), 0.0845560 secs] [Times: user=0.23 sys=0.03, real=0.09 secs] 
4.092: [GC (Allocation Failure) 4.092: [ParNew: 306688K->34048K(306688K), 0.1013723 secs] 342214K->136584K(2063104K), 0.1014307 secs] [Times: user=0.25 sys=0.05, real=0.10 secs] 
... cut for brevity ...
11.292: [GC (Allocation Failure) 11.292: [ParNew: 306686K->34048K(306688K), 0.0857219 secs] 971599K->779148K(2063104K), 0.0857875 secs] [Times: user=0.26 sys=0.04, real=0.09 secs] 
12.140: [GC (Allocation Failure) 12.140: [ParNew: 306688K->34046K(306688K), 0.0821774 secs] 1051788K->856120K(2063104K), 0.0822400 secs] [Times: user=0.25 sys=0.03, real=0.08 secs] 
12.989: [GC (Allocation Failure) 12.989: [ParNew: 306686K->34048K(306688K), 0.1086667 secs] 1128760K->931412K(2063104K), 0.1087416 secs] [Times: user=0.24 sys=0.04, real=0.11 secs] 
13.098: [GC (CMS Initial Mark) [1 CMS-initial-mark: 897364K(1756416K)] 936667K(2063104K), 0.0041705 secs] [Times: user=0.02 sys=0.00, real=0.00 secs] 
13.102: [CMS-concurrent-mark-start]
13.341: [CMS-concurrent-mark: 0.238/0.238 secs] [Times: user=0.36 sys=0.01, real=0.24 secs] 
13.341: [CMS-concurrent-preclean-start]
13.350: [CMS-concurrent-preclean: 0.009/0.009 secs] [Times: user=0.03 sys=0.00, real=0.01 secs] 
13.350: [CMS-concurrent-abortable-preclean-start]
13.878: [GC (Allocation Failure) 13.878: [ParNew: 306688K->34047K(306688K), 0.0960456 secs] 1204052K->1010638K(2063104K), 0.0961542 secs] [Times: user=0.29 sys=0.04, real=0.09 secs] 
14.366: [CMS-concurrent-abortable-preclean: 0.917/1.016 secs] [Times: user=2.22 sys=0.07, real=1.01 secs] 
14.366: [GC (CMS Final Remark) [YG occupancy: 182593 K (306688 K)]14.366: [Rescan (parallel) , 0.0291598 secs]14.395: [weak refs processing, 0.0000232 secs]14.395: [class unloading, 0.0117661 secs]14.407: [scrub symbol table, 0.0015323 secs]14.409: [scrub string table, 0.0003221 secs][1 CMS-remark: 976591K(1756416K)] 1159184K(2063104K), 0.0462010 secs] [Times: user=0.14 sys=0.00, real=0.05 secs] 
14.412: [CMS-concurrent-sweep-start]
14.633: [CMS-concurrent-sweep: 0.221/0.221 secs] [Times: user=0.37 sys=0.00, real=0.22 secs] 
14.633: [CMS-concurrent-reset-start]
14.636: [CMS-concurrent-reset: 0.002/0.002 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]

在點頭同意這個結(jié)論之前，讓我們看看來自同一個 JVM 啟動收集的垃圾收集日志的輸出。顯然- XX ： + PrintGCDetails 告訴我們一個不同且更詳細的故事：

基于這些信息，我們可以看到12次 Minor GC 后開始有些和上面不一樣了。沒有運行兩次Full GC，這不同的地方在于單個GC在永久代中不同階段運行了兩次：

最初的標記階段，用了0.0041705秒也就是4ms左右。這個階段會暫?！叭澜纾?stop-the-world）”的事件，停止所有應(yīng)用程序的線程，然后開始標記。

并行執(zhí)行標記和清洗階段。這些都是和應(yīng)用程序線程并行的。 最后 Remark 階段，花費了0.0462010秒約46ms。這個階段會再次暫停所有的事件。 并行執(zhí)行清理操作。正如其名，此階段也是并行的，不會停止其他線程。

所以，正如我們從垃圾回收日志中所看到的那樣，實際上只是執(zhí)行了 Major GC 去清理老年代空間而已，而不是執(zhí)行了兩次 Full GC。

感謝各位的閱讀，以上就是“Minor GC、Major GC、Full GC有什么區(qū)別”的內(nèi)容了，經(jīng)過本文的學習后，相信大家對Minor GC、Major GC、Full GC有什么區(qū)別這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關(guān)知識點的文章，歡迎關(guān)注！