一、GC概要 JVM堆相關(guān)知識    為什么先說JVM堆?    JVM的堆是java對象的活動空間，程序中的類的對象從中分配空間，其存儲著正在運行著的應(yīng)用程序用到的所有對象。這些對象的建立方式就是那些new一類的操作，當對象無用后，是GC來負責這個無用的對象(地球人都知道)。JVM堆    (1) 新域：存儲所有新成生的對象    (2) 舊域：新域中的對象，經(jīng)過了一定次數(shù)的GC循環(huán)后，被移入舊域    (3)永久域：存儲類和方法對象，從配置的角度看，這個域是獨立的，不包括在JVM堆內(nèi)。默認為4M。 新域會被分為3個部分：1.第一個部分叫Eden。(伊甸園？？可能是因為亞當和夏娃是人類最早的活動對象？)2.另兩個部分稱為輔助生存空間(幼兒園)，我這里一個稱為A空間(From sqace)，一個稱為B空間(To Space)。

二、GC淺談GC的工作目的很明確：在堆中，找到已經(jīng)無用的對象，并把這些對象占用的空間收回使其可以重新利用.大多數(shù)垃圾回收的 算法思路都是一致的：把所有對象組成一個集合，或可以理解為樹狀結(jié)構(gòu)，從樹根開始找，只要可以找到的都是活動對象，如果找不到，這個對象就是凋零的昨日黃 花，應(yīng)該被回收了。在sun 的文檔說明中，對JVM堆的新域，是采用coping算法，該算法的提出是為了克服句柄的開銷和解決堆碎片的垃圾回收。它開始時把堆分成一個對象面和多個 空閑面，程序從對象面為對象分配空間，當對象滿了，基于 coping算法的垃圾收集就從根集中掃描活動對象，并將每個活動對象復(fù)制到空閑面(使得活動對象所占的內(nèi)存之間沒有空閑洞)，這樣空閑面變成了對象面， 原來的對象面變成了空閑面，程序會在新的對象面中分配內(nèi)存。 對于新生成的對象，都放在Eden中；當Eden充滿時（小孩太多 了），GC將開始工作，首先停止應(yīng)用程序的運行，開始收集垃圾，把所有可找到的對象都復(fù)制到A空間中，一旦當A空間充滿，GC就把在A空間中可找到的對象 都復(fù)制到B空間中(會覆蓋原有的存儲對象)，當B空間滿的時間，GC就把在B空間中可找到的對象都復(fù)制到A空間中，AB在這個過程中互換角色，那位客官說 了：拷來拷去，煩不煩啊？什么時候是頭？您別急，在活動對象經(jīng)過一定次數(shù)的GC操作后，這些活動對象就會被放到舊域中。對于這些活動對象，新域的幼兒園生 活結(jié)束了。新域為什么要這么折騰？起初在這塊我也很迷糊，又查了些資料，原來是這樣：應(yīng)用程序生成的絕大部分對象都是短命的，copying算法最理想的 狀態(tài)是，所有移出Eden的對象都會被收集，因為這些都是短命鬼，經(jīng)過一定次數(shù)的GC后應(yīng)該被收集，那么移入到舊域的對象都是長命的，這樣可以防止AB空 間的來回復(fù)制影響應(yīng)用程序。實際上這種理想狀態(tài)是很難達到的，應(yīng)用程序中不可避免地存在長命的對象，copying算法的發(fā)明者要這些對象都盡量放在新域 中，以保證小范圍的復(fù)制，壓縮舊域的開銷可比新域中的復(fù)制大得多(舊域在下面說)。對于舊域，采用的是tracing算法的一種，稱為標記-清除-壓縮收 集器，注意，這有一個壓縮，這是個開銷挺大的操作。垃圾回收主要是對Young Generation塊和Old Generation塊內(nèi)存進行回收，YG用來放新產(chǎn)生的對象，經(jīng)過幾次回收還沒回收掉的對象往OG中移動，對YG進行垃圾回收又叫做MinorGC，對 OG垃圾回收又叫MajorGC，兩塊內(nèi)存回收互不干涉。二、Gc 流程：[older generation][survivor 1][survivor 2][eden]*young generation=eden + survivor1.當eden滿了，觸發(fā)young GC；2.young GC做2件事：一，去掉一部分沒用的object；二，把老的還被引用的object發(fā)到survior里面，等下幾次GC以后，survivor再放到old里面。3.當old滿了，觸發(fā)full GC。full GC很消耗內(nèi)存，把old，young里面大部分垃圾回收掉。這個時候用戶線程都會被block。 三、young generation比例越大,不一定最好。將young的大小設(shè)置為大于總堆大小的一半時會造成效率低下。如果設(shè)置得過小，又會因為young generation收集程序不得不頻繁運行而造成瓶頸。 四、總結(jié)從上面的推導(dǎo)可以得出很多結(jié)論，下面是前輩的經(jīng)驗總結(jié)與自已的認識1.JVM堆的大小決定了GC的運行時間。如果JVM堆的大小超過一定的限度，那么GC的運行時間會很長。2.對象生存的時間越長，GC需要的回收時間也越長，影響了回收速度。3.大多數(shù)對象都是短命的，所以，如果能讓這些對象的生存期在GC的一次運行周期內(nèi)，wonderful！4.應(yīng)用程序中，建立與釋放對象的速度決定了垃圾收集的頻率。5.如果GC一次運行周期超過3-5秒，這會很影響應(yīng)用程序的運行，如果可以，應(yīng)該減少JVM堆的大小了。6.前輩經(jīng)驗之談：通常情況下，JVM堆的大小應(yīng)為物理內(nèi)存的80%。 五、看案例jmap -heap 2343Attaching to PRocess ID 2343, please wait...Debugger attached successfully.Server compiler detected.JVM version is 11.0-b16 using thread-local object allocation.Parallel GC with 8 thread(s) Heap Configuration:   MinHeapFreeRatio = 40   MaxHeapFreeRatio = 70   MaxHeapSize      = 4294967296 (4096.0MB)   NewSize          = 2686976 (2.5625MB)   MaxNewSize       = -65536 (-0.0625MB)   OldSize          = 5439488 (5.1875MB)   NewRatio         = 2                  （YG，OG 大小比為1：2）   SurvivorRatio    = 8   PermSize         = 21757952 (20.75MB)   MaxPermSize      = 268435456 (256.0MB) Heap Usage:PS Young GenerationEden Space:   capacity = 1260060672 (1201.6875MB)   used     = 64868288 (61.86322021484375MB)   free     = 1195192384 (1139.8242797851562MB)   5.148028935546367% usedFrom Space:   capacity = 85524480 (81.5625MB)   used     = 59457648 (56.70323181152344MB)   free     = 26066832 (24.859268188476562MB)   69.52120375359195% usedTo Space:   capacity = 85852160 (81.875MB)   used     = 0 (0.0MB)   free     = 85852160 (81.875MB)   0.0% used~~~~~~~~~~~~~~~~~~~~~~~~~~這三塊為上面所說的YG大小和使用情況PS Old Generation   capacity = 2291138560 (2185.0MB)   used     = 1747845928 (1666.8757705688477MB)   free     = 543292632 (518.1242294311523MB)   76.28722062099989% used~~~~~~~~~~~~~~~~~~~~~~~~~~OG大小和使用情況PS Perm Generation   capacity = 108265472 (103.25MB)   used     = 107650712 (102.6637191772461MB)   free     = 614760 (0.5862808227539062MB)   99.43217353728436% used 這臺機器簡單說YG內(nèi)存1G，OG內(nèi)存2G，總內(nèi)存4G在這樣的配置下，GC運行情況：jstat -gcutil -h5 2343 4s 100  S0     S1     E      O      P     YGC     YGCT    FGC    FGCT     GCT   79.82   0.00  75.34  78.55  99.44   7646 1221.668   398 2052.993 3274.661  0.00  79.52   0.62  78.63  99.44   7647 1221.782   398 2052.993 3274.775 這里發(fā)生了一次YG GC，也就是MinorGC，耗時0.12s  0.00  79.52  28.95  78.63  99.44   7647 1221.782   398 2052.993 3274.775  0.00  79.52  46.34  78.63  99.44   7647 1221.782   398 2052.993 3274.775 同時可以看到總共進行了398次Major GC 總耗時2052.993 所以每次Major GC時間為：2052.993/398=5.16秒這是個很嚴重的問題，進行Major GC的時候程序會暫停，無法響應(yīng)，居然會暫停5秒多，這誰都無法接受吧 :)同樣Minor GC進行了7647次，總用時1221.782 平均時間為0.16秒，算是可以接受 

再來看看修改配置后：jmap -heap 14103Attaching to process ID 14103, please wait...Debugger attached successfully.Server compiler detected.JVM version is 11.0-b16 using parallel threads in the new generation.using thread-local object allocation.Concurrent Mark-Sweep GC Heap Configuration:   MinHeapFreeRatio = 40   MaxHeapFreeRatio = 70   MaxHeapSize      = 4294967296 (4096.0MB)   NewSize          = 536870912 (512.0MB)   MaxNewSize       = 536870912 (512.0MB)   OldSize          = 5439488 (5.1875MB)   NewRatio         =4                         YG：OG          1：4          SurvivorRatio    = 8   PermSize         = 268435456 (256.0MB)   MaxPermSize      = 268435456 (256.0MB) Heap Usage:New Generation (Eden + 1 Survivor Space):   capacity = 483196928 (460.8125MB)   used     = 428284392 (408.4438247680664MB)   free     = 54912536 (52.368675231933594MB)   88.63557841162434% usedEden Space:   capacity = 429522944 (409.625MB)   used     = 404788608 (386.0364990234375MB)   free     = 24734336 (23.5885009765625MB)   94.24144010337199% usedFrom Space:   capacity = 53673984 (51.1875MB)   used     = 23495784 (22.407325744628906MB)   free     = 30178200 (28.780174255371094MB)   43.77499534970238% usedTo Space:   capacity = 53673984 (51.1875MB)   used     = 0 (0.0MB)   free     = 53673984 (51.1875MB)   0.0% used~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~YG 大小和使用狀態(tài)concurrent mark-sweep generation:   capacity = 3758096384 (3584.0MB)   used     = 1680041600 (1602.2125244140625MB)   free     = 2078054784 (1981.7874755859375MB)   44.70459052494594% used~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~OG 大小和使用狀態(tài)Perm Generation:   capacity = 268435456 (256.0MB)   used     = 128012184 (122.0819320678711MB)   free     = 140423272 (133.9180679321289MB)   47.688254714012146% used 在這個配置下，GC運行情況：jstat -gcutil -h5 14103 4s 100  S0     S1     E      O      P     YGC     YGCT    FGC    FGCT     GCT   47.49   0.00  64.82  46.08  47.69  20822 2058.631    68   22.734 2081.365  0.00  37.91  38.57  46.13  47.69  20823 2058.691    68   22.734 2081.425 這里發(fā)生了一次YG GC，也就是MinorGC，耗時0.06s 46.69   0.00  15.19  46.18  47.69  20824 2058.776    68   22.734 2081.510 46.69   0.00  74.59  46.18  47.69  20824 2058.776    68   22.734 2081.510  0.00  40.29  19.95  46.24  47.69  20825 2058.848    68   22.734 2081.582 MajorGC平均時間：22.734/68=0.334秒（上面是5秒多吧）MinorGC平均時間：2058.691/20823=0.099秒（比上面略少