2. 程式人生 > >關於G1 GC中Mixed GC的分析

關於G1 GC中Mixed GC的分析

阿新 • • 發佈：2019-01-30

關於G1的Mixed GC，網上所有的資料都千篇一律，說分為XX階段，有的階段STW，有的階段併發。。。

但實際分析日誌過程中，總覺得很難理解，Mixed GC到底是一個併發的過程，還是一次GC？

本文不打算總結G1的原理（這裡、這裡、這裡 都有非常詳細的GC原理說明），而是通過一次完整的日誌分析，來巨集觀地理解Mixed GC的過程。

下面的例子中，堆記憶體20G。環境中，存在大量H-OBJ（巨大物件）的申請，用於分析Mixed GC非常合適。

【分析過程】

先看一段GC日誌。

 5347275.209: [G1Ergonomics (Concurrent Cycles) request concurrent cycle initiation, reason: requested by GC cause, GC cause: G1 Humongous Allocation]
{Heap before GC invocations=15872 (full 0):
 garbage-first heap   total 20971520K, used 14601677K [0x00000002c0000000, 0x00000002c0805000, 0x00000007c0000000)
  region size 8192K, 761 young (6234112K), 16 survivors (131072K)
 Metaspace       used 317657K, capacity 368621K, committed 461500K, reserved 1443840K
  class space    used 36695K, capacity 50034K, committed 66556K, reserved 1048576K
↑↑↑↑↑↑  回收前的記憶體分佈，總共使用了14601677K，年輕代 6234112K，老年代=14601677K-6234112K=8367565K ↑↑↑↑↑↑ 

 5347275.209: [G1Ergonomics (Concurrent Cycles) initiate concurrent cycle, reason: concurrent cycle initiation requested]
2018-06-04T21:30:42.445+0200: 5347275.210: [GC pause (G1 Humongous Allocation) (young) (initial-mark) 5347275.212: [G1Ergonomics (CSet Construction) start
 
 choosing CSet, _pending_cards: 96649, predicted base time: 68.52 ms, remaining time: 131.48 ms, target pause time: 200.00 ms]
 5347275.212: [G1Ergonomics (CSet Construction) add young regions to CSet, eden: 745 regions, survivors: 16 regions, predicted young region time: 50.85 ms]
 5347275.212: [G1Ergonomics (CSet Construction) finish choosing CSet, eden: 745
 
 regions, survivors: 16 regions, old: 0 regions, predicted pause time: 119.37 ms, target pause time: 200.00 ms]
, 0.4266532 secs]
   [Parallel Time: 321.3 ms, GC Workers: 23]
      [GC Worker Start (ms): Min: 5347275212.8, Avg: 5347275212.9, Max: 5347275213.0, Diff: 0.2]
      [Ext Root Scanning (ms): Min: 5.1
 
, Avg: 5.8, Max: 14.9, Diff: 9.9, Sum: 132.6]
      [Update RS (ms): Min: 4.3, Avg: 13.7, Max: 16.1, Diff: 11.7, Sum: 315.5]
         [Processed Buffers: Min: 26, Avg: 38.7, Max: 57, Diff: 31, Sum: 889]
      [Scan RS (ms): Min: 25.4, Avg: 27.2, Max: 27.6, Diff: 2.2, Sum: 626.7]
      [Code Root Scanning (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.1]
      [Object Copy (ms): Min: 272.3, Avg: 272.9, Max: 273.5, Diff: 1.2, Sum: 6275.8]
      [Termination (ms): Min: 0.0, Avg: 0.6, Max: 0.9, Diff: 0.9, Sum: 13.6]
         [Termination Attempts: Min: 1, Avg: 344.6, Max: 421, Diff: 420, Sum: 7925]
      [GC Worker Other (ms): Min: 0.0, Avg: 0.1, Max: 0.2, Diff: 0.2, Sum: 2.9]
      [GC Worker Total (ms): Min: 320.1, Avg: 320.3, Max: 320.5, Diff: 0.4, Sum: 7367.1]
      [GC Worker End (ms): Min: 5347275533.1, Avg: 5347275533.2, Max: 5347275533.3, Diff: 0.2]
   [Code Root Fixup: 0.0 ms]
   [Code Root Purge: 0.0 ms]
   [Clear CT: 1.1 ms]
   [Other: 104.1 ms]
      [Choose CSet: 0.0 ms]
      [Ref Proc: 95.5 ms]
      [Ref Enq: 0.2 ms]
      [Redirty Cards: 0.3 ms]
      [Humongous Register: 0.1 ms]
      [Humongous Reclaim: 3.0 ms]
      [Free CSet: 1.8 ms]
   [Eden: 5960.0M(11.9G)->0.0B(11.4G) Survivors: 128.0M->576.0M Heap: 13.9G(20.0G)->3942.4M(20.0G)]
Heap after GC invocations=15873 (full 0):
 garbage-first heap   total 20971520K, used 4037037K [0x00000002c0000000, 0x00000002c0805000, 0x00000007c0000000)
  region size 8192K, 72 young (589824K), 72 survivors (589824K)
 Metaspace       used 317657K, capacity 368621K, committed 461500K, reserved 1443840K
  class space    used 36695K, capacity 50034K, committed 66556K, reserved 1048576K
↑↑↑↑↑↑  回收後的記憶體分佈，總共使用了4037037K ，年輕代 589824K，老年代=4037037K -589824K=3447213K ↑↑↑↑↑↑ 
}
 [Times: user=7.34 sys=0.07, real=0.42 secs]

由於G1 Humongous Allocation（申請H-OBJ），觸發了concurrent cycle。開始concurrent cycle有2個條件：

  1. 申請H-OBJ（申請的記憶體大於Region的一半）
  2. 堆佔用率達到45%。

同時，伴隨著一次Yong GC，開始了initial-mark。我們把這次稱做 第一次回收。

從回收前後的老年代記憶體對比，可以看出，在這個階段，老年代的記憶體也是被回收了的。說明這裡已經在做Mixed GC了。

另一方面，在第二次GC發生前，出現了大量的下面的日誌（節選）。原因是，正在執行mixed collections。可見，Mixed GC指的不是一次GC，而是一個過程，這個過程從initial-mark開始。什麼時候結束呢？繼續跟蹤日誌。

······
 5347633.884: [G1Ergonomics (Concurrent Cycles) do not request concurrent cycle initiation, reason: still doing mixed collections, occupancy: 10057940992 bytes, allocation request: 5767184 bytes, threshold: 9663676380 bytes (45.00 %), source: concurrent humongous allocation]
 5347633.952: [G1Ergonomics (Concurrent Cycles) do not request concurrent cycle initiation, reason: still doing mixed collections, occupancy: 10066329600 bytes, allocation request: 51380240 bytes, threshold: 9663676380 bytes (45.00 %), source: concurrent humongous allocation]
 5347633.967: [G1Ergonomics (Concurrent Cycles) do not request concurrent cycle initiation, reason: still doing mixed collections, occupancy: 10125049856 bytes, allocation request: 11534352 bytes, threshold: 9663676380 bytes (45.00 %), source: concurrent humongous allocation]
 5347633.970: [G1Ergonomics (Concurrent Cycles) do not request concurrent cycle initiation, reason: still doing mixed collections, occupancy: 10141827072 bytes, allocation request: 11534352 bytes, threshold: 9663676380 bytes (45.00 %), source: concurrent humongous allocation]
 5347634.107: [G1Ergonomics (Concurrent Cycles) do not request concurrent cycle initiation, reason: still doing mixed collections, occupancy: 10158604288 bytes, allocation request: 11534352 bytes, threshold: 9663676380 bytes (45.00 %), source: concurrent humongous allocation]
······

下面，又一次GC開始了，我們稱之為第二次回收。我們看到，此時，年輕代的記憶體是 8568832K，回顧一下第一次回收，[Eden: 5960.0M(11.9G)->0.0B(11.4G) Survivors: 128.0M->576.0M Heap: 13.9G(20.0G)->3942.4M(20.0G)]，光Eden區就分配了 11.4G，遠大於 8568832K。而此時，記憶體已經完全耗盡，記憶體使用量為 19580258K。這說明了記憶體區域是不固定的。即使規劃了11.4G的記憶體給Eden，但如果大量的記憶體分配直接發生在老年代，也會佔用本就屬於年輕代的空間。

再對比一下survior區，第一次回收完後，和本次開始回收時，大小都是 589824K，說明在整個過程中，survior沒有變化。

{Heap before GC invocations=15874 (full 0):
 garbage-first heap   total 20971520K, used 19580258K [0x00000002c0000000, 0x00000002c0805000, 0x00000007c0000000)
  region size 8192K, 1046 young (8568832K), 72 survivors (589824K)
 Metaspace       used 317657K, capacity 368621K, committed 461500K, reserved 1443840K
  class space    used 36695K, capacity 50034K, committed 66556K, reserved 1048576K
2018-06-04T21:36:50.482+0200: 5347643.246: [GC pause (G1 Humongous Allocation) (young) 5347643.250: [G1Ergonomics (CSet Construction) start choosing CSet, _pending_cards: 340287, predicted base time: 138.33 ms, remaining time: 61.67 ms, target pause time: 200.00 ms]
 5347643.250: [G1Ergonomics (CSet Construction) add young regions to CSet, eden: 974 regions, survivors: 72 regions, predicted young region time: 59.52 ms]
 5347643.250: [G1Ergonomics (CSet Construction) finish choosing CSet, eden: 974 regions, survivors: 72 regions, old: 0 regions, predicted pause time: 197.85 ms, target pause time: 200.00 ms]
 5347643.252: [G1Ergonomics (Heap Sizing) attempt heap expansion, reason: region allocation request failed, allocation request: 4194296 bytes]
 5347643.252: [G1Ergonomics (Heap Sizing) expand the heap, requested expansion amount: 4194296 bytes, attempted expansion amount: 8388608 bytes]
 5347643.252: [G1Ergonomics (Heap Sizing) did not expand the heap, reason: heap already fully expanded]
 5347654.363: [G1Ergonomics (Concurrent Cycles) do not request concurrent cycle initiation, reason: still doing mixed collections, occupancy: 10745806848 bytes, allocation request: 0 bytes, threshold: 9663676380 bytes (45.00 %), source: end of GC]
 5347654.363: [G1Ergonomics (Mixed GCs) start mixed GCs, reason: candidate old regions available, candidate old regions: 296 regions, reclaimable: 1391084520 bytes (6.48 %), threshold: 5.00 %]
 (to-space exhausted), 11.1174306 secs]
   [Parallel Time: 9875.9 ms, GC Workers: 23]
      [GC Worker Start (ms): Min: 5347643250.4, Avg: 5347643250.5, Max: 5347643250.6, Diff: 0.2]
      [Ext Root Scanning (ms): Min: 2.0, Avg: 3.3, Max: 11.9, Diff: 9.9, Sum: 75.5]
      [Update RS (ms): Min: 42.9, Avg: 50.1, Max: 53.7, Diff: 10.8, Sum: 1152.0]
         [Processed Buffers: Min: 69, Avg: 82.1, Max: 97, Diff: 28, Sum: 1888]
      [Scan RS (ms): Min: 22.4, Avg: 25.5, Max: 25.9, Diff: 3.5, Sum: 586.2]
      [Code Root Scanning (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.2]
      [Object Copy (ms): Min: 9794.0, Avg: 9796.1, Max: 9797.3, Diff: 3.3, Sum: 225310.2]
      [Termination (ms): Min: 0.0, Avg: 0.6, Max: 0.8, Diff: 0.8, Sum: 14.1]
         [Termination Attempts: Min: 1, Avg: 52.3, Max: 71, Diff: 70, Sum: 1203]
      [GC Worker Other (ms): Min: 0.0, Avg: 0.1, Max: 0.2, Diff: 0.2, Sum: 2.2]
      [GC Worker Total (ms): Min: 9875.5, Avg: 9875.7, Max: 9875.8, Diff: 0.3, Sum: 227140.5]
      [GC Worker End (ms): Min: 5347653126.1, Avg: 5347653126.2, Max: 5347653126.3, Diff: 0.2]
   [Code Root Fixup: 0.0 ms]
   [Code Root Purge: 0.0 ms]
   [Clear CT: 1.6 ms]
   [Other: 1239.9 ms]
      [Evacuation Failure: 1226.4 ms]
      [Choose CSet: 0.0 ms]
      [Ref Proc: 0.5 ms]
      [Ref Enq: 0.0 ms]
      [Redirty Cards: 2.1 ms]
      [Humongous Register: 0.1 ms]
      [Humongous Reclaim: 4.9 ms]
      [Free CSet: 0.7 ms]
   [Eden: 7792.0M(11.4G)->0.0B(1016.0M) Survivors: 576.0M->8192.0K Heap: 18.7G(20.0G)->10174.5M(20.0G)]
Heap after GC invocations=15875 (full 0):
 garbage-first heap   total 20971520K, used 10418682K [0x00000002c0000000, 0x00000002c0805000, 0x00000007c0000000)
  region size 8192K, 1 young (8192K), 1 survivors (8192K)
 Metaspace       used 317657K, capacity 368621K, committed 461500K, reserved 1443840K
  class space    used 36695K, capacity 50034K, committed 66556K, reserved 1048576K
}
 [Times: user=34.56 sys=4.63, real=11.12 secs]

從GC pause (G1 Humongous Allocation) (young)可以看出，這是一次Yang GC。其原因是在Eden申請不到記憶體。

5347654.363: [G1Ergonomics (Mixed GCs) start mixed GCs, reason: candidate old regions available, candidate old regions: 296 regions, reclaimable: 1391084520 bytes (6.48 %), threshold: 5.00 %]
 (to-space exhausted), 11.1174306 secs]

由於可回收的老年代記憶體為 1391084520 bytes，佔整個堆記憶體的比例為6.48%，超過了啟動Mixed GC的threshold（5%），所以開始Mixed GC。

同時，發現了to-space exhausted，因為記憶體回收的第一步，就是把在Eden和from-survivor中存活的物件移動到to-survivor中，但此時，整個堆都空間了。

可以，我們看到，回收完後，老年代的記憶體是10418682K - 8192K = 10410490K，而回收前是19580258K - 8568832K = 11011426K，並沒有減少很多。可見，此時的老年代中，大量的記憶體還無法被回收。

從[Times: user=34.56 sys=4.63, real=11.12 secs]可以看出，這次GC停頓了11.12秒，一個十分誇張的停頓時間。這與記憶體耗盡，老年代無法回收，肯定有很大的關係。

再看下一次回收，第三次回收。

由於 第二次回收 後，給Eden分配的空間僅為1016.0M，所以，只隔了1分多鐘，就開始了這一次回收。

{Heap before GC invocations=15875 (full 0):
 garbage-first heap   total 20971520K, used 11712123K [0x00000002c0000000, 0x00000002c0805000, 0x00000007c0000000)
  region size 8192K, 128 young (1048576K), 1 survivors (8192K)
 Metaspace       used 317657K, capacity 368621K, committed 461500K, reserved 1443840K
  class space    used 36695K, capacity 50034K, committed 66556K, reserved 1048576K
2018-06-04T21:38:39.835+0200: 5347752.600: [GC pause (G1 Evacuation Pause) (mixed) 5347752.601: [G1Ergonomics (CSet Construction) start choosing CSet, _pending_cards: 133986, predicted base time: 100.64 ms, remaining time: 99.36 ms, target pause time: 200.00 ms]
 5347752.601: [G1Ergonomics (CSet Construction) add young regions to CSet, eden: 127 regions, survivors: 1 regions, predicted young region time: 6.26 ms]
 5347752.601: [G1Ergonomics (CSet Construction) finish adding old regions to CSet, reason: reclaimable percentage not over threshold, old: 41 regions, max: 256 regions, reclaimable: 1069764520 bytes (4.98 %), threshold: 5.00 %]
 5347752.601: [G1Ergonomics (CSet Construction) finish choosing CSet, eden: 127 regions, survivors: 1 regions, old: 41 regions, predicted pause time: 111.85 ms, target pause time: 200.00 ms]
 5347752.686: [G1Ergonomics (Concurrent Cycles) do not request concurrent cycle initiation, reason: still doing mixed collections, occupancy: 10452205568 bytes, allocation request: 0 bytes, threshold: 9663676380 bytes (45.00 %), source: end of GC]
 5347752.686: [G1Ergonomics (Mixed GCs) do not continue mixed GCs, reason: reclaimable percentage not over threshold, candidate old regions: 255 regions, reclaimable: 1069764520 bytes (4.98 %), threshold: 5.00 %]
, 0.0866559 secs]
   [Parallel Time: 44.1 ms, GC Workers: 23]
      [GC Worker Start (ms): Min: 5347752602.1, Avg: 5347752602.2, Max: 5347752602.3, Diff: 0.2]
      [Ext Root Scanning (ms): Min: 3.4, Avg: 4.4, Max: 14.0, Diff: 10.5, Sum: 101.5]
      [Update RS (ms): Min: 6.5, Avg: 16.0, Max: 17.0, Diff: 10.5, Sum: 369.0]
         [Processed Buffers: Min: 20, Avg: 45.5, Max: 71, Diff: 51, Sum: 1047]
      [Scan RS (ms): Min: 2.5, Avg: 2.6, Max: 2.8, Diff: 0.4, Sum: 60.0]
      [Code Root Scanning (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.0]
      [Object Copy (ms): Min: 19.7, Avg: 19.9, Max: 20.5, Diff: 0.8, Sum: 457.6]
      [Termination (ms): Min: 0.2, Avg: 0.8, Max: 0.9, Diff: 0.7, Sum: 17.8]
         [Termination Attempts: Min: 1, Avg: 101.0, Max: 136, Diff: 135, Sum: 2324]
      [GC Worker Other (ms): Min: 0.0, Avg: 0.0, Max: 0.1, Diff: 0.1, Sum: 1.1]
      [GC Worker Total (ms): Min: 43.6, Avg: 43.8, Max: 43.9, Diff: 0.3, Sum: 1007.2]
      [GC Worker End (ms): Min: 5347752646.0, Avg: 5347752646.0, Max: 5347752646.1, Diff: 0.1]
   [Code Root Fixup: 0.0 ms]
   [Code Root Purge: 0.0 ms]
   [Clear CT: 1.1 ms]
   [Other: 41.4 ms]
      [Choose CSet: 0.1 ms]
      [Ref Proc: 36.7 ms]
      [Ref Enq: 0.1 ms]
      [Redirty Cards: 0.2 ms]
      [Humongous Register: 0.1 ms]
      [Humongous Reclaim: 0.2 ms]
      [Free CSet: 0.7 ms]
   [Eden: 1016.0M(1016.0M)->0.0B(8160.0M) Survivors: 8192.0K->128.0M Heap: 11.2G(20.0G)->10011.7M(20.0G)]
Heap after GC invocations=15876 (full 0):
 garbage-first heap   total 20971520K, used 10251938K [0x00000002c0000000, 0x00000002c0805000, 0x00000007c0000000)
  region size 8192K, 16 young (131072K), 16 survivors (131072K)
 Metaspace       used 317657K, capacity 368621K, committed 461500K, reserved 1443840K
  class space    used 36695K, capacity 50034K, committed 66556K, reserved 1048576K
}
 [Times: user=1.01 sys=0.01, real=0.09 secs]

這次回收被標記為mixed（[GC pause (G1 Evacuation Pause) (mixed)）。這與第二次回收時的[G1Ergonomics (Mixed GCs) start mixed GCs有關。

5347752.686: [G1Ergonomics (Mixed GCs) do not continue mixed GCs, reason: reclaimable percentage not over threshold, candidate old regions: 255 regions, reclaimable: 1069764520 bytes (4.98 %), threshold: 5.00 %]

上面這句話，說老年代可回收的記憶體只佔4.98%，不到5%，因此不再繼續Mixed GC。至此，Mixed GC結束。可以從下一次的GC證明這一點。

下面是新一輪GC，與第一次回收一樣，由於申請H-OBJ，且堆佔用率超過了45%，又開始了initial-mark的過程。

 5347809.743: [G1Ergonomics (Concurrent Cycles) request concurrent cycle initiation, reason: requested by GC cause, GC cause: G1 Humongous Allocation]
{Heap before GC invocations=15876 (full 0):
 garbage-first heap   total 20971520K, used 10948258K [0x00000002c0000000, 0x00000002c0805000, 0x00000007c0000000)
  region size 8192K, 102 young (835584K), 16 survivors (131072K)
 Metaspace       used 317657K, capacity 368621K, committed 461500K, reserved 1443840K
  class space    used 36695K, capacity 50034K, committed 66556K, reserved 1048576K
 5347809.743: [G1Ergonomics (Concurrent Cycles) initiate concurrent cycle, reason: concurrent cycle initiation requested]
2018-06-04T21:39:36.979+0200: 5347809.744: [GC pause (G1 Humongous Allocation) (young) (initial-mark) 5347809.744: [G1Ergonomics (CSet Construction) start choosing CSet, _pending_cards: 30512, predicted base time: 74.40 ms, remaining time: 125.60 ms, target pause time: 200.00 ms]
 5347809.744: [G1Ergonomics (CSet Construction) add young regions to CSet, eden: 86 regions, survivors: 16 regions, predicted young region time: 6.12 ms]
 5347809.744: [G1Ergonomics (CSet Construction) finish choosing CSet, eden: 86 regions, survivors: 16 regions, old: 0 regions, predicted pause time: 80.53 ms, target pause time: 200.00 ms]
, 0.0569457 secs]
   [Parallel Time: 29.4 ms, GC Workers: 23]
      [GC Worker Start (ms): Min: 5347809745.5, Avg: 5347809745.6, Max: 5347809745.7, Diff: 0.2]
      [Ext Root Scanning (ms): Min: 5.9, Avg: 6.8, Max: 17.3, Diff: 11.3, Sum: 156.0]
      [Update RS (ms): Min: 0.0, Avg: 8.0, Max: 10.5, Diff: 10.5, Sum: 184.3]
         [Processed Buffers: Min: 0, Avg: 24.8, Max: 56, Diff: 56, Sum: 570]
      [Scan RS (ms): Min: 0.0, Avg: 0.0, Max: 0.3, Diff: 0.2, Sum: 0.9]
      [Code Root Scanning (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.0]
      [Object Copy (ms): Min: 10.9, Avg: 13.3, Max: 13.9, Diff: 3.0, Sum: 306.3]
      [Termination (ms): Min: 0.0, Avg: 0.1, Max: 0.2, Diff: 0.2, Sum: 2.9]
         [Termination Attempts: Min: 1, Avg: 54.6, Max: 69, Diff: 68, Sum: 1256]
      [GC Worker Other (ms): Min: 0.0, Avg: 0.1, Max: 0.1, Diff: 0.1, Sum: 1.4]
      [GC Worker Total (ms): Min: 28.2, Avg: 28.3, Max: 28.5, Diff: 0.3, Sum: 651.9]
      [GC Worker End (ms): Min: 5347809773.9, Avg: 5347809773.9, Max: 5347809774.0, Diff: 0.1]
   [Code Root Fixup: 0.0 ms]
   [Code Root Purge: 0.0 ms]
   [Clear CT: 0.9 ms]
   [Other: 26.6 ms]
      [Choose CSet: 0.0 ms]
      [Ref Proc: 21.9 ms]
      [Ref Enq: 0.1 ms]
      [Redirty Cards: 1.9 ms]
      [Humongous Register: 0.0 ms]
      [Humongous Reclaim: 0.0 ms]
      [Free CSet: 0.4 ms]
   [Eden: 688.0M(8160.0M)->0.0B(8248.0M) Survivors: 128.0M->80.0M Heap: 10.4G(20.0G)->9960.3M(20.0G)]
Heap after GC invocations=15877 (full 0):
 garbage-first heap   total 20971520K, used 10199311K [0x00000002c0000000, 0x00000002c0805000, 0x00000007c0000000)
  region size 8192K, 10 young (81920K), 10 survivors (81920K)
 Metaspace       used 317657K, capacity 368621K, committed 461500K, reserved 1443840K
  class space    used 36695K, capacity 50034K, committed 66556K, reserved 1048576K
}
 [Times: user=0.54 sys=0.01, real=0.06 secs]

【總結】

  1. Mixed GC是一個很長的過程，從initial-mark開始，直到G1Ergonomics (Mixed GCs) do not continue mixed GCs。這期間，可以發生多次GC（本例中開始和結束中間只有一次，因為啟動Mixed GC時，可回收記憶體僅佔6%，且中途並沒有產生大量的H-OBJ，所以一次回收後，就小於5%的門限。）。
  2. 從initial-mark開始的每一次GC，都會回收老年代的記憶體。
  3. 在Mixed GC執行期間，如果有H-OBJ的申請，將不會再次觸發concurrent cycle initiation。
  4. 觸發記憶體回收，只有2種情況：
    • Eden耗盡
    • 堆記憶體耗盡
  5. 如果由於堆記憶體耗盡而觸發GC，會導致長時間停頓。

【一個無關緊要的發現】

每一次GC開始時，都會列印類似Heap before GC invocations=15872 (full 0)的一句日誌。其中invocations=15872是自JVM啟動以來，執行GC的次數。

一般情況情況下，每次GC的發生，這個值都會加1。但從我們的例子中可以看到，第一次回收時，這個值是15872，而第二次回收時，這個值就變成了15874。

據觀察，每次initial-mark後的GC，這個ID都會跳過1，原因不明。

相關推薦

關於G1 GC中Mixed GC的分析

關於G1的Mixed GC，網上所有的資料都千篇一律，說分為XX階段，有的階段STW，有的階段併發。。。 但實際分析日誌過程中，總覺得很難理解，Mixed GC到底是一個併發的過程，還是一次GC？ 本文不打算總結G1的原理（這裡、這裡、這裡 都有非常詳細的G

Android中GC機制的相關分析

前言 我們知道在Android開發中，由於有垃圾回收機制，所以我們不用花費太多的心思在記憶體分配或釋放上，但是這不是說我們要完全忽略。我們知道系統分配給每個應用程式的記憶體是有限的，這個記憶體的上限叫做“堆大小”(Heap Size)，不同的手機，所分配的大小

【達內課程】Android中的GC垃圾回收機制與記憶體洩漏

當main()方法執行完，main()方法中的區域性變數都會彈棧，從棧當中銷燬 當左側棧中的e2和e銷燬後，右側中的兩個物件就是垃圾 java底層有一種GC垃圾回收機制，在java程式執行時，GC執行緒會不斷找尋垃圾，是的話會清除掉 當我們點選模擬機的返回鍵時，發生了什麼 當G

GC 可達性分析演算法

在主流的商用程式語言的主要實現中，都是稱通過可達性分析（Reachability Analysis）來判定物件是否存活的，這個演算法的基本思路就是通過一系列的稱為“GC Roots“的物件作為起始點，從這些節點開始向下搜尋，搜尋所走過的路程成為引用鏈（Reference Chain）,當一個物件

JDK8的GC型別 與 高併發生產環境中不同GC型別帶來的效能提升

    記一次專案中，在JDK8環境下，並行GC月併發GC在Restful介面中體現差異。     當今國內第三大流量電商(某多多)，博主所在公司在前一段時間和他們有產品合作，他們對我們產品提出了非常嚴格的要求：一分鐘時間範圍內介面響應時間大於300MS的

Java中的GC（Garbage Collection）

1、如何判斷是否是要回收的物件？ 1）引用計數演算法：給物件新增一個計數器，每當有一個引用它時，計數器值加1；當引用失效時，計數器值減1。當計數器減為0時，說明該物件不能再被使用，此時該物件就可以被回收。 缺點：當有迴圈引用時，會一直得不到回收，例如變數a和變數b之間互相引用，形成迴圈引用。

JAVA 10原始碼閱讀筆記之JEP-307（G1的並行Full GC）

# 1. 背景 JEP-307解決了G1垃圾回收器的一個嚴重的問題，截止到Java 9，G1的Full GC採用的是單執行緒演算法，嚴重影響效能，無法利用到多核能力進行垃圾回收。JEP-307修復了此問題，發生Full GC時允許使用多個執行緒進行並行回收。 # 2. G1

怎樣在IDEA中檢視GC日誌

引言 今天在看書的時候，在講到垃圾收集器與記憶體分配策略的章節時，文中有如下一段程式碼： public class ReferenceCountingGC { public Object instance = null; private static final i

Java中什麼樣的物件才能作為gc root，gc roots有哪些

GC管理的主要區域是Java堆，一般情況下只針對堆進行垃圾回收。方法區、棧和本地方法區不被GC所管理,因而選擇這些區域內的物件作為GC roots,被GC roots引用的物件不被GC回收。 詳細： GC Root 常說的GC(Garbage Collector) roots，特指的是垃

GC的物件標記分析法

1、引用計數法 引用計數法原理很簡單，給每個新生物件配備一個計數器。當此物件被引用，計數器+1；當此物件的引用被斷開，計數器-1。GC會定時詢問這些計數器，當該計數器的值降到0就認為物件死亡，物件會被標記，等待清理。更高階的引用計數實現會引入“弱引用”的概念來打破某些已知的迴圈引用，但那是另

Elasticsearch Log 中的 GC 日誌

image 如果你關注過 elasticsearch 的日誌，可能會看到如下類似的內容： [2018-06-30T17:57:23,848][WARN ][o.e.m.j.JvmGcMonitorService] [qoo--eS] [gc][228384] overhead, spent

GC可達性分析回收演算法 解決迴圈引用問題 強引用弱引用

JVM有一個回收演算法是引用計數演算法，每當物件被引用一次，就+1，釋放一個引用就-1，當垃圾回收時，引用計數為0的物件就會被GC掉。但這個方法有個問題，就是無法解決迴圈引用的問題。 迴圈引用就是物件A引用了物件B，物件B引用了物件A，構成了一個引用環。彼此都沒發揮什麼作用

Java 9 中的 GC 調優基礎

在經過了幾次跳票之後，Java 9終於在原計劃日期的整整一年之後釋出了正式版。Java 9引入了很多新的特性，除了閃瞎眼的Module System和REPL，最重要的變化我認為是預設GC（Garbage Collector）修改為新一代更復雜、更全面、效能更好的G1（Gar

JVM gc引數設定與分析

原文： 概述 java的最大好處是自動垃圾回收，這樣就無需我們手動的釋放物件空間了，但是也產生了相應的負效果，gc是需要時間和資源的，不好的gc會嚴重影響系統的系能，因此良好的gc是JVM的高效能的保證。JVM堆分為新生代，舊生代和年老代，新生代可用的gc方式有：序列

關於JVM 中的GC Root

由於最近各種實習筆試，所以大部分的精力都放在了資料結構學習上；今天偶然間想起 JVM 的垃圾回收，試著回想了一下；發現很多東西都不是那麼清晰了。 那麼回到正題，看過JVM的同學應該都知道hotspot

Minor GC 中 MaxTenuringThreshold 和 TargetSurvivorRatio 引數說明

以-Xms20M -Xmx20M -Xmn10M -XX:SurvivorRatio=1 -XX:+UseSerialGC -XX:MaxTenuringThreshold=3 -XX:+PrintTenuringDistribution -XX:+PrintGCDetails 執行上述程式碼。 [GC [D

Java9中的GC 調優

垃圾收集器與記憶體分配策略參考目錄： 在經過了幾次跳票之後，Java 9終於在原計劃日期的整整一年之後釋出了正式版。Java 9引入了很多新的特性，除了閃瞎眼的Module System和REPL，最重要的變化我認為是預設GC（Garbage Collector）修改為新一代更復雜、更全面、效能更

Java中的GC是什麼? 為什麼要有GC?

GC是垃圾收集的意思（Gabage Collection）,記憶體處理是程式設計人員容易出現問題的地方，忘記或者錯誤的記憶體回收會導致程式或系統的不穩定甚至崩潰，Java提供的GC功能可以自動監測物件是否超過作用域從而達到自動回收記憶體的目的，Java語言沒有提供釋放已分配記

一次Full GC 過程的日誌分析

基礎概念： Full GC,新生代，舊生代和持久代都發生GC，說明這次GC是發生了Stop-The-World的 ParNew GC發生區域，和收集器有關，這裡是ParNew收集器，如果為Serial收集器，則顯示DefNew。如果Parallel Scavenge收集器

python中的GC機制

和java一樣 python也有垃圾自動回收機制，但實現方法與java並不相同 python中以引用計數為主，零代為輔 1 引用計數機制 python裡每一個東西都是物件，它們的核心就是一個結構體：PyObject typedef struct_