靈魂拷問

為什么需要？

對什么東西？

在什么時候？

做什么事情？

一、為什么需要

應用程序對資源操作，通常簡單分為以下幾個步驟：

為對應的資源分配內存

初始化內存

使用資源

清理資源

釋放內存

手動管理的話，容易造成以下典型問題：

程序員忘記釋放內存

應用程序訪問已經釋放的內存

從而導致了內存泄漏、數據內容亂碼等

總結：無法自動化的內存管理方式極易產生bug，影響系統穩定性，源源不斷的類似bug影響開發人員編程積極性

二、對什么東西

垃圾收集主要是針對堆和方法區里不使用的對象進行的。程序計數器、虛擬機棧和本地方法棧這三個區域屬于線程私有的，只存在于線程的生命周期內，線程結束之后就會消失，因此不需要對這三個區域進行垃圾回收。

JVM是一個內存中的虛擬機，目前有三大Java虛擬機：HotSpot，oracle JRockit，IBM J9

Class Loader：根據特定格式，加載Class文件到內存

Runtime Data Area：JVM內存空間結構模型(也叫運行時數據區域)

Execution Engine：對命令進行解析

Native Interface：融合不同開發語言的原生庫為Java所用，在執行時加載Native Libraries

2.1 運行時數據區域(Runtime Data Area)

JDK 1.6 運行時數據區域

JVM內存模型-JDK1.8

線程私有

程序計數器(字節碼指令 no OOM)

虛擬機棧(Java方法 SOF&OOM)

本地方法棧(native方法 SOF&OOM)

線程共享

MetaSpace(類加載信息 OOM)

Java堆(數組和類對象 OOM，常量池)

JDK1.7中把運行時常量池放到了堆中。

JDK1.8及之后，由于每次Full GC之后永久代大小都會改變，經常OOM，所以把方法區(一種JVM規范，永久代和元空間都是它的實現方式，之前HotSpot虛擬機把這個作為永久代來進行垃圾回收)去掉了，移至元空間，而其原本的數據也分成兩部分，元空間存儲類的元信息，靜態變量和常量池等都放到了堆中。

Java堆

所有對象都在這里分配內存，是垃圾收集的主要區域(GC 堆)

現代的垃圾收集器基本都是采用分代收集算法，其主要的思想是針對不同類型的對象采取不同的垃圾回收算法?？梢詫⒍逊殖蓛蓧K:

新生代(Young Generation)：一個Eden，兩個Survivor區，HopSpot默認大小8:1:1

老年代(Old Generation)

HotSpot Heap Structure

永久代(HotSpot的方法區)在JDK1.8之后移除，Java堆里只有新生代和老年代了。

堆不需要連續內存，并且可以動態增加其內存，增加失敗會拋出 OutOfMemoryError 異常。

2.2 怎么判斷一個對象是否可被回收

2.2.1 引用計數算法

為對象添加一個引用計數器

當對象增加一個引用時計數器加 1，引用失效時計數器減 1

引用計數為 0 的對象可被回收

優點：執行效率高，程序執行受影響較小

缺點：無法檢測出循環引用的情況，導致內存泄漏，因此Java虛擬機不實用引用技術算法

2.2.2 可達性分析算法

以 GC Roots為起始點進行搜索，可達的對象都是存活的，不可達的對象可被回收

可以作為GC Roots的對象

虛擬機棧中引用的對象(棧幀中的局部變量表)

方法區中的常量引用的對象

方法區中的類靜態屬性引用的對象

本地方法棧中JNI(native方法)的引用對象

可被回收

未到達的對象并非是“非死不可”的，若要宣判一個對象死亡，至少需要經歷兩次標記階段

st=>start: 第一次標記&第一次篩選

e=>end: 被回收

callFinallize=>condition: 是否有必要執行該對象的finallize方法

putFQueue=>operation: 放入F-Queue隊列，虛擬機自動建立低優先級的Finalizer線程

selfSave=>condition: 是否在finalize中拯救了自己(只能拯救一次)

removeFromQueue=>operation: 從即將回收的集合中移除，等待下次回收

st->callFinallize

callFinallize(yes)->putFQueue->selfSave

selfSave(no)->e

selfSave(yes)->removeFromQueue

callFinallize(no)->e

如果對象可達性分析之后GC Roots搜索不到，會被第一次標記并進行一次篩選(是否有必要執行該對象的finallize方法)

未覆蓋或者已執行的 --> 回收

已覆蓋未執行的 --> 放入一個叫F-Queue的隊列中，之后會有虛擬機自動建立的、低優先級的Finalizer線程去執行，而虛擬機不必要等待該線程執行結束，即虛擬機只負責建立線程，其他的讓此線程區處理

對F-Queue中的對象進行第二次標記

如果對象在finalize方法中拯救了自己(只能拯救一次)，即關聯上了GC Roots引用鏈，則第二次標記的時候會將該對象從“即將回收”的集合中移除

如果對象還是沒有拯救自己，則會被回收

package com.dyl.myspringboot;

/**

* @author dyl

* @date 2019/08/06

*/

public class FinalizeTest {

private static FinalizeTest finalize;

@Override

protected void finalize() throws Throwable {

super.finalize();

System.out.println("method finalize is running");

finalize = this;

}

public static void main(String[] args) throws Exception {

finalize = new FinalizeTest();

// 第一次執行，finalize方法會自救

finalize = null;

System.gc();

Thread.sleep(500);

if (finalize != null) {

System.out.println("I'm alive");

} else {

System.out.println("I'm dead");

}

// 第二次執行，finalize方法已經執行過

finalize = null;

System.gc();

Thread.sleep(500);

if (finalize != null) {

System.out.println("I'm alive");

} else {

System.out.println("I'm dead");

}

}

}

2.3 引用類型

無論是通過引用計數算法判斷對象的引用數量，還是通過可達性分析算法判斷對象是否可達，判定對象是否可被回收都與引用有關

Java 提供了四種強度不同的引用類型

2.3.1 強引用

被強引用關聯的對象不會被回收

使用 new一個新對象的方式來創建強引用

Object obj = new Object();

2.3.2 軟引用

被軟引用關聯的對象只有在內存不夠的情況下才會被回收

使用 SoftReference 類來創建軟引用

Object obj = new Object();

SoftReference sf = new SoftReference(obj);

obj = null; // 使對象只被軟引用關聯

2.3.3. 弱引用

被弱引用關聯的對象一定會被回收，也就是說它只能存活到下一次垃圾回收發生之前

使用 WeakReference 類來創建弱引用

Object obj = new Object();

WeakReference wf = new WeakReference(obj);

obj = null;

2.3.4 虛引用

又稱為幽靈引用或者幻影引用，一個對象是否有虛引用的存在，不會對其生存時間造成影響，也無法通過虛引用得到一個對象

為一個對象設置虛引用的唯一目的是能在這個對象被回收時收到一個系統通知

使用PhantomReference 來創建虛引用

Object obj = new Object();

PhantomReference pf = new PhantomReference(obj, null);

obj = null;

強引用 > 軟引用 > 弱引用 > 虛引用

引用類型

被垃圾回收時間

用途

生存時間

強引用

從來不會

對象的一般狀態

JVM停止運行時終止

軟引用

在內存不足時

對象緩存

內存不足時終止

弱引用

在垃圾回收時

對象緩存

GC運行后終止

虛引用

Unknown

標記、哨兵

Unknown

總結：引用計數為0的對象；從GC Roots開始搜索不到的對象，而且經過一次標記、清理，仍然沒有復活的對象

三、在什么時候

3.1 內存分配策略

對象優先在 Eden 分配

大多數情況下，對象在新生代 Eden 上分配，當 Eden 空間不夠時，發起 Minor GC

大對象直接進入老年代

大對象是指需要連續內存空間的對象，最典型的大對象是那種很長的字符串以及數組。 經常出現大對象會提前觸發垃圾收集以獲取足夠的連續空間分配給大對象。

-XX:PretenureSizeThreshold大于此值的對象直接在老年代分配，避免在 Eden 和 Survivor 之間的大量內存復制

長期存活的對象進入老年代

為對象定義年齡計數器，對象在 Eden 出生并經過 Minor GC 依然存活，將移動到 Survivor 中，年齡就增加 1 歲， 增加到一定年齡則移動到老年代中。

-XX:MaxTenuringThreshold用來定義年齡的閾值

動態對象年齡判定

虛擬機并不是永遠要求對象的年齡必須達到MaxTenuringThreshold才能晉升老年代，如果在 Survivor 中相同年齡 所有對象大小的總和大于 Survivor 空間的一半，則年齡大于或等于該年齡的對象可以直接進入老年代，無需等到 MaxTenuringThreshold 中要求的年齡。

3.2 內存回收策略

Minor GC

回收新生代，因為新生代對象存活時間很短，因此 Minor GC 會頻繁執行，執行的速度一般也會比較快

Full GC

回收老年代和新生代，老年代對象其存活時間長，因此 Full GC 很少執行，執行速度會比 Minor GC慢很多

3.3 觸發條件

3.3.1 Minor GC

當Eden空間滿時，就將觸發一次 Minor GC

3.3.2 Full GC

調用System.gc()

只是建議虛擬機執行 Full GC，但是虛擬機不一定真正去執行。不建議使用這種方式，而是讓虛擬機管理內存

老年代空間不足

老年代空間不足的常見場景為 大對象直接進入老年代、長期存活的對象進入老年代等

為了避免，應當盡量不要創建過大的對象以及數組。除此之外，可以通過-Xmn虛擬機參數調大新生代的大小，讓對象盡量在新生代被回收掉，不進入老年代。還可以通過-XX:MaxTenuringThreshold調大對象進入老年代的年齡，讓對象在新生代多存活一段時間

JDK 1.7 及以前的永久代空間不足

在 JDK 1.7 及以前，HotSpot 虛擬機中的方法區是用永久代實現的，永久代中存放的為一些 Class 的信息、常量、靜態變量等數據。

當系統中要加載的類、反射的類和調用的方法較多時，永久代可能會被占滿，在未配置為采用 CMS GC 的情況下也會執行 Full GC。如果經過 Full GC 仍然回收不了，那么虛擬機會拋出 java.lang.OutOfMemoryError。

可采用增大永久代空間或轉為使用 CMS GC的方法來避免

CMS GC時出現promotion failed，concurrent mode failure

預留的內存不夠存放浮動垃圾

總結：新生代的Eden區空間滿時觸發Minor GC；系統在不可測的時間調用System.gc()方法、老年代空間不足、jdk1.7及以前的永久代空間不足等情況會觸發Full GC

四、做什么事情

4.1 垃圾收集算法

4.1.1 標記-清除算法(Mark and Sweep)

標記：從根集合GC Roots進行掃描，對存活的對象進行標記

清除：對堆內存從頭到尾進行線性遍歷，回收不可達對象內存

缺點

標記和清除過程效率都不高

會產生大量不連續的內存碎片，導致無法給大對象分配內存

4.1.2 標記-整理算法(Compacting)

標記：從根集合進行掃描，對存活的對象進行標記

清除：移動所有存活的對象，且按照內存地址次序依次排列，然后將末端內存地址以后的內存全部回收

優點

避免內存的不連續行

不用設置兩塊內存互換

適用于存活率高的場景

缺點

需要移動大量對象，處理效率低

4.1.3 復制算法(Copying)

分為對象面和空閑面

對象在對象面上創建

存活的對象被從對象面復制到空閑面

將對象面所有對象內存清除

優點：

解決碎片化問題

順序分配內存，簡單高效

適用于對象存活率低的場景

4.1.4 分代收集算法(Generational Collector)

垃圾回收算法的組合拳

按照對象生命周期的不同劃分區域以采取不同的垃圾回收算法

目的：提高JVM的回收效率

新生代：復制算法：HotSpot默認值 Eden : Survivor = 8 : 1

老年代：標記-清除 or 標記-整理

4.2 垃圾回收器

HotSpot的7個垃圾收集器

以上是 HotSpot 虛擬機中的 7 個垃圾收集器，連線表示垃圾收集器可以配合使用

單線程與多線程

單線程指的是垃圾收集器只使用一個線程，而多線程使用多個線程

串行與并行

串行指的是垃圾收集器與用戶程序交替執行，這意味著在執行垃圾收集的時候需要停頓用戶程序;并行指的是垃圾收集器和用戶程序同時執行。除了 CMS 和 G1 之外，其它垃圾收集器都是以串行的方式執行

4.2.1. Serial 收集器

它是單線程的收集器，只會使用一個線程進行垃圾收集工作。

它的優點是簡單高效，在單個 CPU 環境下，由于沒有線程交互的開銷，因此擁有最高的單線程收集效率。

它是 Client 場景下的默認新生代收集器，因為在該場景下內存一般來說不會很大。它收集一兩百兆垃圾的停頓時間可以控制在一百多毫秒以內，只要不是太頻繁，這點停頓時間是可以接受的

4.2.2. ParNew 收集器

它是 Serial 收集器的多線程版本。

它是 Server 場景下默認的新生代收集器，除了性能原因外，主要是因為除了 Serial 收集器，只有它能與 CMS 收集器配合使用

4.2.3 Parallel Scavenge 收集器

與 ParNew 一樣是多線程收集器。

其它收集器目標是盡可能縮短垃圾收集時用戶線程的停頓時間，而它的目標是達到一個可控制的吞吐量，因此它被稱為吞吐量優先收集器。這里的吞吐量指 CPU 用于運行用戶程序的時間占總時間的比值。

縮短停頓時間是以犧牲吞吐量和新生代空間來換取的:新生代空間變小，垃圾回收變得頻繁，導致吞吐量下降。

4.2.4 Serial Old 收集器

是 Serial 收集器的老年代版本，也是給 Client 場景下的虛擬機使用。如果用在 Server 場景下，它有兩大用途

在 JDK 1.5 以及之前版本(Parallel Old 誕生以前)中與 Parallel Scavenge 收集器搭配使用

作為 CMS 收集器的后備預案，在并發收集發生 Concurrent Mode Failure 時使用

4.2.5 Parallel Old 收集器

是 Parallel Scavenge 收集器的老年代版本。

在注重吞吐量以及 CPU 資源敏感的場合，都可以優先考慮 Parallel Scavenge 加 Parallel Old 收集器

4.2.6 CMS 收集器

CMS(Concurrent Mark Sweep)，Mark Sweep 指的是標記 - 清除算法

分為以下四個流程：

初始標記：僅僅只是標記一下 GC Roots 能直接關聯到的對象，速度很快，需要停頓

并發標記：進行 GC Roots Tracing 的過程，它在整個回收過程中耗時最長，不需要停頓

重新標記：為了修正并發標記期間因用戶程序繼續運作而導致標記產生變動的那一部分對象的標記記錄，需要停頓

并發清除：不需要停頓

在整個過程中耗時最長的并發標記和并發清除過程中，收集器線程都可以與用戶線程一起工作，不需要進行停頓。

具有以下缺點：

吞吐量低：低停頓時間是以犧牲吞吐量為代價的，導致 CPU 利用率不夠高

無法處理浮動垃圾，可能出現 Concurrent Mode Failure。浮動垃圾是指并發清除階段由于用戶線程繼續運行而產生的垃圾，這部分垃圾只能到下一次 GC 時才能進行回收。由于浮動垃圾的存在，因此需要預留出一部分內存，意味著 CMS 收集不能像其它收集器那樣等待老年代快滿的時候再回收。如果預留的內存不夠存放浮動垃圾，就會出現 Concurrent Mode Failure，這時虛擬機將臨時啟用 Serial Old 來替代 CMS

標記 - 清除算法導致的空間碎片，往往出現老年代空間剩余，但無法找到足夠大連續空間來分配當前對象，不得不提前觸發一次 Full GC

4.2.7 G1 收集器

G1(Garbage-First)，它是一款面向服務端應用的垃圾收集器，在多 CPU 和大內存的場景下有很好的性能。

HotSpot 開發團隊賦予它的使命是未來可以替換掉 CMS 收集器

堆被分為新生代和老年代，其它收集器進行收集的范圍都是整個新生代或者老年代，而 G1 可以直接對新生代和老年代一起回收

總結：觸發GC時，JVM根據分代收集算法，使用相應的垃圾收集器來回收垃圾

個人觀點

Java GC，打個不太形象的比喻，就好比拿掃把掃地：

哪些是垃圾(可達性分析，把有用的標記)

哪里的垃圾(Runtime Data Area是房間，Java堆是地板)

什么時候掃？(GC觸發條件)

用什么掃？(垃圾回收器)

怎么掃？(垃圾收集算法)

JVM性能調優常用參數

參數名稱

含義

默認值

說明

-Xms

初始堆大小

物理內存的1/64(<1GB)

默認(MinHeapFreeRatio參數可以調整)空余堆內存小于40%時，JVM就會增大堆直到-Xmx的最大限制

-Xmx

最大堆大小

物理內存的1/4(<1GB)

默認(MaxHeapFreeRatio參數可以調整)空余堆內存大于70%時，JVM會減少堆直到-Xms的最小限制

-Xmn

新生代大小(1.4or lator)

注意：此處的大小是(eden+ 2 survivor space)。與jmap -heap中顯示的New gen是不同的。整個堆大小=新生代大小+老年代大小+永久代大小。增大新生代后,將會減小老年代大小。此值對系統性能影響較大,Sun官方推薦配置為整個堆的3/8

-XX:NewSize

設置新生代大小(for 1.3/1.4)

-XX:MaxNewSize

新生代最大值(for 1.3/1.4)

-XX:PermSize

設置永久代(perm gen)初始值

物理內存的1/64

jdk1.8之后不生效

-XX:MaxPermSize

設置永久代最大值

物理內存的1/4

jdk1.8之后不生效

-Xss

每個線程的堆棧大小

JDK5.0以后每個線程堆棧大小為1M，以前每個線程堆棧大小為256K。更具應用的線程所需內存大小進行調整。在相同物理內存下，減小這個值能生成更多的線程。但是操作系統對一個進程內的線程數還是有限制的，不能無限生成，經驗值在3000~5000左右。一般小的應用，如果棧不是很深，應該是128k夠用的，大的應用建議使用256k。這個選項對性能影響比較大，需要嚴格的測試

-XX:ThreadStackSize

Thread Stack Size

(0 means use default stack size) [Sparc: 512; Solaris x86: 320 (was 256 prior in 5.0 and earlier); Sparc 64 bit: 1024; Linux amd64: 1024 (was 0 in 5.0 and earlier); all others 0.]

-XX:NewRatio

新生代(包括Eden和兩個Survivor區)與老年代的比值(除去永久代)

-XX:NewRatio=4表示新生代與老年代所占比值為1:4,新生代占整個堆棧的1/5Xms=Xmx并且設置了Xmn的情況下，該參數不需要進行設置。

-XX:SurvivorRatio

Eden區與Survivor區的大小比值

HotSpot默認設置為8,即兩個Survivor區與一個Eden區的比值為2:8，一個Survivor區占整個新生代的1/10

-XX:LargePageSizeInBytes

內存頁的大小不可設置過大， 會影響Perm的大小

=128m

-XX:+UseFastAccessorMethods

原始類型的快速優化

-XX:+DisableExplicitGC

關閉System.gc()

這個參數需要嚴格的測試

-XX:MaxTenuringThreshold

垃圾最大年齡

如果設置為0的話，則新生代對象不經過Survivor區，直接進入老年代。對于老年代比較多的應用，可以提高效率。如果將此值設置為一個較大值，則新生代對象會在Survivor區進行多次復制，這樣可以增加對象再新生代的存活時間，增加在新生代即被回收的概率。該參數只有在串行GC時才有效

-XX:+AggressiveOpts

加快編譯

-XX:+UseBiasedLocking

鎖機制的性能改善

-Xnoclassgc

禁用垃圾回收

-XX:SoftRefLRUPolicyMSPerMB

每兆堆空閑空間中SoftReference的存活時間

1s

softly reachable objects will remain alive for some amount of time after the last time they were referenced. The default value is one second of lifetime per free megabyte in the heap

-XX:PretenureSizeThreshold

對象超過多大是直接在老年代分配

0

單位字節 新生代采用Parallel Scavenge GC時無效，另一種直接在老年代分配的情況是大的數組對象，且數組中無外部引用對象

-XX:TLABWasteTargetPercent

TLAB占eden區的百分比

1%

-XX:+CollectGen0First

FullGC時是否先YGC

false

JVM性能調優工具

先進入到jdk的目錄

[dengyulong@09:20:14]~$ /usr/libexec/java_home -V

Matching Java Virtual Machines (1):

1.8.0_201, x86_64: "Java SE 8" /Library/Java/JavaVirtualMachines/jdk1.8.0_201.jdk/Contents/Home

/Library/Java/JavaVirtualMachines/jdk1.8.0_201.jdk/Contents/Home

[dengyulong@09:23:50]~$ cd /Library/Java/JavaVirtualMachines/jdk1.8.0_201.jdk/Contents/Home/bin

[dengyulong@09:27:16]/Library/Java/JavaVirtualMachines/jdk1.8.0_201.jdk/Contents/Home/bin$ ls

appletviewer java javap jdeps jmc jstat orbd rmiregistry unpack200

extcheck javac javapackager jhat jps jstatd pack200 schemagen wsgen

idlj javadoc jcmd jinfo jrunscript jvisualvm policytool serialver wsimport

jar javafxpackager jconsole jjs jsadebugd keytool rmic servertool xjc

jarsigner javah jdb jmap jstack native2ascii rmid tnameserv

1. jps

查看JVM中運行的進程狀態信息

[dengyulong@09:33:03]~$ jps

16224 Bootstrap

30529

27157 Bootstrap

53030 Main

24376 Bootstrap

52637 Launcher

52845 Launcher

52846 Bootstrap

53150 Jps

2. jstack

查看某個Java進程內的線程堆棧信息

$ jstack [pid]

3. jstat

查看各個區內存和GC的情況

-class

顯示加載class的數量，及所占空間等信息

[dengyulong@10:29:28]~$ jstat -class 30529

Loaded Bytes Unloaded Bytes Time

145689 253316.0 61218 80613.1 102.79

Loaded : 已經裝載的類的數量

Bytes : 裝載類所占用的字節數

Unloaded：已經卸載類的數量

Bytes：卸載類的字節數

Time：裝載和卸載類所花費的時間

-compiler

顯示VM實時編譯(JIT)的數量等信息

[dengyulong@15:04:33]~$ jstat -compiler 30529

Compiled Failed Invalid Time FailedType FailedMethod

402707 25 0 5391.41 1 com/intellij/psi/impl/compiled/StubBuildingVisitor visitMethod

Compiled：編譯任務執行數量

Failed：編譯任務執行失敗數量

Invalid ：編譯任務執行失效數量

Time ：編譯任務消耗時間

FailedType：最后一個編譯失敗任務的類型

FailedMethod：最后一個編譯失敗任務所在的類及方法

-gc

顯示gc相關的堆信息，查看gc的次數，及時間

[dengyulong@15:04:40]~$ jstat -gc 30529

S0C S1C S0U S1U EC EU OC OU MC MU CCSC CCSU YGC YGCT FGC FGCT GCT

38336.0 38336.0 10431.9 0.0 306944.0 93751.1 769408.0 475510.8 567576.0 517967.3 72696.0 63593.5 9158 131.185 683 362.332 493.517

S0C：新生代中第一個 survivor 的容量(Byte)

S1C：新生代中第二個 survivor 的容量(Byte)

S0U：新生代中第一個 survivor 目前已使用空間(Byte)

S1U：新生代中第二個 survivor 目前已使用空間(Byte)

EC：新生代中 Eden 的容量(Byte)

EU：新生代中 Eden 目前已使用空間(Byte)

OC：老年代的容量(Byte)

OU：老年代目前已使用空間(Byte)

MC：metaspace(元空間)的容量(Byte)

MU：metaspace(元空間)目前已使用空間(Byte)

YGC：從應用程序啟動到采樣時新生代中gc次數

YGCT：從應用程序啟動到采樣時新生代gc(Minor GC)所用時間(s)

FGC：從應用程序啟動到采樣時老年代gc(Full GC)次數

FGCT：從應用程序啟動到采樣時老年代gc(Full GC)所用時間(s)

GCT：從應用程序啟動到采樣時gc用的總時間(s)

-gcutil

統計gc信息

[dengyulong@15:17:22]~$ jstat -gcutil 30529

S0 S1 E O M CCS YGC YGCT FGC FGCT GCT

0.00 0.00 53.89 63.02 91.26 87.48 9159 131.207 684 363.946 495.153

S0：新生代中第一個survivor已使用的占當前容量百分比

S1：新生代中第二個survivor已使用的占當前容量百分比

E：新生代中Eden已使用的占當前容量百分比

O：老年代已使用的占當前容量百分比

M：Metaspace已使用的占當前容量百分比

YGC：從應用程序啟動到采樣時新生代中gc次數

YGCT：從應用程序啟動到采樣時新生代中gc所用時間(s)

FGC：從應用程序啟動到采樣時老年代GC(Full GC)次數

FGCT：從應用程序啟動到采樣時老年代GC(Full GC)所用時間(s)

GCT：從應用程序啟動到采樣時gc用的總時間(s)

其他的如：-gccapacity、-gcmetacapacity、-gcnew、-gcnewcapacity、-gcold、-gcoldcapacity、-gccause、-printcompilation按需使用，這里不多做介紹

4. jvisualvm

JDK自帶監控程序

jvisualvm的監控界面

總結

以上是生活随笔為你收集整理的java gc什么意思_对Java GC的简单理解的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。