jvm打出gc命令

⑴ JVM GC 日誌詳解

本文採用的JDK版本：

設置JVM GC格式日誌的主要參數包括如下8個：

本文假設讀者已經熟悉JVM 內存結構。

如果想開啟GC日誌的信息，可以通過設置如下的參數任一參數：

如果只設置 -XX:+PrintGC 那麼列印的日誌如下所示：

1、 GC 表示是一次YGC（Young GC）

2、 Allocation Failure 表示是失敗的類型

3、 68896K->5080K 表示年輕代從68896K降為5080K

4、 256000K 表示整個堆的大小

5、 0.0041139 secs 表示這次GC總計所用的時間

在JDK 8中， -verbose:gc 是 -XX:+PrintGC 一個別稱，日誌格式等價與： -XX:+PrintGC ，。

不過在 JDK 9 中 -XX:+PrintGC被標記為 deprecated 。

-verbose:gc 是一個標準的選項， -XX:+PrintGC 是一個實驗的選項，建議使用 -verbose:gc 替代 -XX:+PrintGC

參考： Difference between -XX:+PrintGC and -verbose:gc

1、 GC 表示是一次YGC（Young GC）

2、 Allocation Failure 表示是失敗的類型

3、PSYoungGen 表示年輕代大小

4、 53248K->2176K 表示年輕代佔用從 53248K 降為 2176K

5、 59392K 表示年輕帶的大小

6、 58161K->7161K 表示整個堆佔用從 53248K 降為 2176K

7、 256000K 表示整個堆的大小

8、 0.0039189 secs 表示這次GC總計所用的時間

9、 [Times: user=0.02 sys=0.01, real=0.00 secs] 分別表示，用戶態佔用時長，內核用時，真實用時。

時間保留兩位小數，四捨五入。

如果加上 -XX:+PrintGCTimeStamps 那麼日誌僅僅比1.1介紹的最前面多了一個時間戳： 1.963 ， 表示從JVM啟動到列印GC時刻用了1.963秒。

如果加上 -XX:+PrintGCDateStamps 那麼日誌僅僅比1.1介紹的最前面多了一個日期時間： 2019-03-05T16:56:15.108+0800 ， 表示列印GC的時刻的時間是 2019-03-05T16:56:15.108+0800 。+0800表示是東8區。

這個參數開啟後，

使用如下參數 -verbose:gc -XX:+PrintHeapAtGC -Xmn64M -Xms256M -Xmx256M

列印日誌如下：

由此可以看出在，列印如下日誌前後

詳細列印出了日誌信息

invocations 表示GC的次數，每次GC增加一次，每次GC前後的invocations相等

1、 Heap before GC invocations=1 表示是第1次GC調用之前的堆內存狀況

2、 {Heap before GC invocations=1 (full 0): 表示是第1次GC調用之後的堆內存狀況

如果使用該參數 -Xloggc 則默認開啟如下兩個參數

如果啟動參數如下： -Xloggc:gc.log -Xmn64M -Xms256M -Xmx256M 則日誌格式如下所示

gc.log 也可以指定絕對的路徑。

在gc.log最前面還會默認列印系統的JDK版本與啟動的參數

此設置 -XX:+PrintReferenceGC可以列印出SoftReference，WeakReference，FinalReference，PhantomReference，JNI Weak Reference幾種引用的數量，以及清理所用的時長，該參數在進行YGC調優時可以排上用場。

具體可以參考佔小狼的一篇實戰： 一次 Young GC 的優化實踐（FinalReference 相關）

CMS日誌分為兩個STW(stop the world)

分別是 init remark （1） 與 remark （7）兩個階段。一般耗時比YGC長約10倍（個人經驗）。

（1）、 [GC (CMS Initial Mark) [1 CMS-initial-mark: 19498K(32768K)] 36184K(62272K), 0.0018083 secs][Times: user=0.01 sys=0.00, real=0.01 secs]

會STO(Stop The World)，這時候的老年代容量為 32768K， 在使用到 19498K 時開始初始化標記。耗時短。

（2）、 [CMS-concurrent-mark-start]

並發標記階段開始

（3）、 [CMS-concurrent-mark: 0.011/0.011 secs] [Times: user=0.02 sys=0.00, real=0.00 secs]

並發標記階段花費時間。

（4）、 [CMS-concurrent-preclean-start]

並發預清理階段，也是與用戶線程並發執行。虛擬機查找在執行並發標記階段新進入老年代的對象(可能會有一些對象從 新生代 晉升到老年代， 或者有一些對象被分配到老年代)。通過重新掃描，減少下一個階段」重新標記」的工作，因為下一個階段會Stop The World。

（5）、 [CMS-concurrent-preclean: 0.001/0.001 secs] [Times: user=0.00 sys=0.00, real=0.01 secs]

並發預清理階段花費時間。

（6）、 [CMS-concurrent-abortable-preclean-start] CMS: abort preclean e to time [CMS-concurrent-abortable-preclean: 0.558/5.093 secs][Times: user=0.57 sys=0.00, real=5.09 secs]

並發可中止預清理階段，運行在並行預清理和重新標記之間，直到獲得所期望的eden空間佔用率。增加這個階段是為了避免在重新標記階段後緊跟著發生一次垃圾清除

（7）、 [GC (CMS Final Remark) [YG occupancy: 16817 K (29504 K)][Rescan (parallel) , 0.0021918 secs][weak refs processing, 0.0000245 secs][class unloading, 0.0044098 secs][scrub symbol table, 0.0029752 secs][scrub string table, 0.0006820 secs][1 CMS-remark: 19498K(32768K)] 36316K(62272K), 0.0104997 secs] [Times: user=0.02 sys=0.00, real=0.01 secs]

會STW(Stop The World)，收集階段，這個階段會標記老年代全部的存活對象，包括那些在並發標記階段更改的或者新創建的引用對象

（8）、 [CMS-concurrent-sweep-start]

並發清理階段開始，與用戶線程並發執行。

（9）、 [CMS-concurrent-sweep: 0.007/0.007 secs] [Times: user=0.01 sys=0.00, real=0.01 secs]

並發清理階段結束，所用的時間。

（10）、 [CMS-concurrent-reset-start]

開始並發重置。在這個階段，與CMS相關數據結構被重新初始化，這樣下一個周期可以正常進行。

（11）、 [CMS-concurrent-reset: 0.000/0.000 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]

並發重置所用結束，所用的時間。

參考：

Geek-Yan : JVM 學習筆記(四) CMS GC日誌詳解

設置JVM GC 性能的有如下參數

新生代大小官網推薦的大小是 3/8 , 如果設置太小，比如 1/10會 導致 Minor GC 與 Major GC 次數增多。

其中n的大小為區間為[0,15],如果高於15，JDK7 會默認15，JDK 8會啟動報錯

發生在CMS GC運行期間，詳情參考：

JVM 調優 —— GC 長時間停頓問題及解決方法

GC的悲觀策略

發生在Minor GC期間

⑵ java命令行執行gc的命令是什麼

System.gc()
不過java虛擬機的gc過程並不是在調用System.gc()之後立即執行的，而是通知虛擬機這部分內存可以回收了，gc的時機是由虛擬機決定，不同的虛擬機gc線程的優先順序不同，一般都比較低

⑶ jvm 什麼情況下會觸發minor gc

當 JVM 無法為一個新的對象分配空間時會觸發 Minor GC。

虛擬機在進行minorGC之前會判斷老年代最大的可用連續空間是否大於新生代的所有對象總空間

1、如果大於的話，直接執行minorGC

2、如果小於，判斷是否開啟HandlerPromotionFailure，沒有開啟直接FullGC

3、如果開啟了HanlerPromotionFailure, JVM會判斷老年代的最大連續內存空間是否大於歷次晉升的大小，如果小於直接執行FullGC

4、如果大於的話，執行minorGC

Minor GC是新生代GC，指的是發生在新生代的垃圾收集動作。由於java對象大都是朝生夕死的，所以Minor GC非常頻繁，一般回收速度也比較快。

(3)jvm打出gc命令擴展閱讀：

Java虛擬機本質上就是一個程序，當它在命令行上啟動的時候，就開始執行保存在某位元組碼文件中的指令。Java語言的可移植性正是建立在Java虛擬機的基礎上。任何平台只要裝有針對於該平台的Java虛擬機，位元組碼文件（.class）就可以在該平台上運行。

引入Java語言虛擬機後，Java語言在不同平台上運行時不需要重新編譯。Java語言使用Java虛擬機屏蔽了與具體平台相關的信息，使得Java語言編譯程序只需生成在Java虛擬機上運行的目標代碼（位元組碼），就可以在多種平台上不加修改地運行。

⑷ Linux使用jstat命令查看jvm的GC情況

Linux 使用jstat命令查看jvm的GC情況

命令格式

jstat命令命令格式：

jstat [Options] vmid[interval] [count]

參數說明：

Options，選項，我們一般使用 -gcutil 查看gc情況

vmid

，VM的進程號，即當前運行的java進程號

interval

，間隔時間，單位為秒或者毫秒

count

，列印次數，如果預設則列印無數次

示例說明

示例

通常運行命令如下：

jstat -gc 12538 5000

即會每5秒一次顯示進程號為12538的java進成的GC情況，

顯示內容如下圖：

結果說明

   S0C：年輕代中第一個survivor（倖存區）的容量 (位元組)

S1C

：年輕代中第二個survivor（倖存區）的容量 (位元組)

S0U

：年輕代中第一個survivor（倖存區）目前已使用空間 (位元組)

S1U

：年輕代中第二個survivor（倖存區）目前已使用空間 (位元組)

EC

：年輕代中Eden（伊甸園）的容量 (位元組)

EU

：年輕代中Eden（伊甸園）目前已使用空間 (位元組)

OC

：Old代的容量 (位元組)

OU

：Old代目前已使用空間 (位元組)

PC

：Perm(持久代)的容量 (位元組)

PU

：Perm(持久代)目前已使用空間 (位元組)

YGC

：從應用程序啟動到采樣時年輕代中gc次數

YGCT

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

FGC

：從應用程序啟動到采樣時old代(全gc)gc次數

FGCT

：從應用程序啟動到采樣時old代(全gc)gc所用時間(s)

GCT

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

NGCMN

：年輕代(young)中初始化(最小)的大小 (位元組)

NGCMX

：年輕代(young)的最大容量 (位元組)

NGC

：年輕代(young)中當前的容量 (位元組)

OGCMN

：old代中初始化(最小)的大小 (位元組)

OGCMX

：old代的最大容量 (位元組)

OGC

：old代當前新生成的容量 (位元組)

PGCMN

：perm代中初始化(最小)的大小 (位元組)

PGCMX

：perm代的最大容量 (位元組)

PGC

：perm代當前新生成的容量 (位元組)

S0

：年輕代中第一個survivor（倖存區）已使用的占當前容量百分比

S1

：年輕代中第二個survivor（倖存區）已使用的占當前容量百分比

E

：年輕代中Eden（伊甸園）已使用的占當前容量百分比

O

：old代已使用的占當前容量百分比

P

：perm代已使用的占當前容量百分比

S0CMX

：年輕代中第一個survivor（倖存區）的最大容量 (位元組)

S1CMX

：年輕代中第二個survivor（倖存區）的最大容量 (位元組)

ECMX

：年輕代中Eden（伊甸園）的最大容量 (位元組)

DSS

：當前需要survivor（倖存區）的容量 (位元組)（Eden區已滿）

TT

： 持有次數限制

MTT

： 最大持有次數限制

⑸ jrockit的jvm的 gc日誌輸出能詳細到什麼程度

可以通過在java命令種加入參數來指定對應的gc類型，列印gc日誌信息並輸出至文件等策略。

GC的日誌是以替換的方式(>)寫入的，而不是追加(>>)，如果下次寫入到同一個文件中的話，以前的GC內容會被清空。

對應的參數列表

-XX:+PrintGC 輸出GC日誌
-XX:+PrintGCDetails 輸出GC的詳細日誌
-XX:+PrintGCTimeStamps 輸出GC的時間戳（以基準時間的形式）
-XX:+PrintGCDateStamps 輸出GC的時間戳（以日期的形式，如 2013-05-04T21:53:59.234+0800）
-XX:+PrintHeapAtGC 在進行GC的前後列印出堆的信息
-Xloggc:../logs/gc.log 日誌文件的輸出路徑

這里使用如下的參數來進行日誌的列印：

-XX:+PrintGCDateStamps -XX:+PrintGCDetails -Xloggc:./gclogs

對於新生代回收的一行日誌，其基本內容如下：

2014-07-18T16:02:17.606+0800: 611.633: [GC 611.633: [DefNew: 843458K->2K(948864K), 0.0059180 secs] 2186589K->1343132K(3057292K), 0.0059490 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]

其含義大概如下：

2014-07-18T16:02:17.606+0800（當前時間戳）: 611.633（時間戳）: [GC（表示Young GC） 611.633: [DefNew（單線程Serial年輕代GC）: 843458K（年輕代垃圾回收前的大小）->2K（年輕代回收後的大小）(948864K（年輕代總大小）), 0.0059180 secs（本次回收的時間）] 2186589K（整個堆回收前的大小）->1343132K（整個堆回收後的大小）(3057292K（堆總大小）), 0.0059490 secs（回收時間）] [Times: user=0.00（用戶耗時） sys=0.00（系統耗時）, real=0.00 secs（實際耗時）]

老年代回收的日誌如下：

2014-07-18T16:19:16.794+0800: 1630.821: [GC 1630.821: [DefNew: 1005567K->111679K(1005568K), 0.9152360 secs]1631.736: [Tenured:
2573912K->1340650K(2574068K), 1.8511050 secs] 3122548K->1340650K(3579636K), [Perm : 17882K->17882K(21248K)], 2.7854350 secs] [Times: user=2.57 sys=0.22, real=2.79 secs]

gc日誌中的最後貌似是系統運行完成前的快照：

Heap
def new generation total 1005568K, used 111158K [0x00000006fae00000, 0x000000073f110000, 0x0000000750350000)
eden space 893888K, 12% used [0x00000006fae00000, 0x0000000701710e90, 0x00000007316f0000)
from space 111680K, 3% used [0x0000000738400000, 0x000000073877c9b0, 0x000000073f110000)
to space 111680K, 0% used [0x00000007316f0000, 0x00000007316f0000, 0x0000000738400000)
tenured generation total 2234420K, used 1347671K [0x0000000750350000, 0x00000007d895d000, 0x00000007fae00000)
the space 2234420K, 60% used [0x0000000750350000, 0x00000007a2765cb8, 0x00000007a2765e00, 0x00000007d895d000)
compacting perm gen total 21248K, used 17994K [0x00000007fae00000, 0x00000007fc2c0000, 0x0000000800000000)
the space 21248K, 84% used [0x00000007fae00000, 0x00000007fbf92a50, 0x00000007fbf92c00, 0x00000007fc2c0000)
No shared spaces configured.

⑹ JVM源碼分析之如何觸發並執行GC線程

線程大家都熟悉，new Thread().start()即會創建一個線程，這里我首先指出一點new Thread()其實並不會創建一個真正的線程，只有在調用了start方法之後才會創建一個線程，這個大家分析下Java代碼就知道了
Thread的構造函數是純Java代碼，start方法會調到一個native方法start0里，而start0其實就是JVM_StartThread這個方法！

⑺ JVM的GC是什麼

最近做了一個需求，給hadoop集群做監控面板，做完了，還得寫說明文檔。如果說，做的時候，是研發主導，那麼做完了，說明文檔，產品經理還是逃不掉 tat

gc（garbage collection），垃圾收集，指JVM用於釋放那些不再使用的對象所佔用的內存。
所以什麼是JVM呢？（作為非技術人員，有一種直覺，看到這種很專業的名詞，就想跳過，但是跳過了，有很大可能會miss掉重要信息，所以我還是研究一下JVM到底是什麼吧！！）

Java Virtual Machine（Java虛擬機）的縮寫。
JVM是java的核心和基礎，在java編譯器和os平台之間的虛擬處理器。
誒，到這里，我突然意識到，JVM是Java虛擬機，為什麼Hadoop的指標會有JVM呢？莫非，Hadoop是用Java開發的，網路了一下，答案，Yes。嘿，還挺反直覺，我還以為是C語言開發的（沒有證據，就是直覺），現實生活中存在的很多直覺其實是不正確的。

最後一句話，也作為6月的座右銘

同樣，在項目管理或AI商業化過程中，同理，我們不因當前的不完美而沮喪，因為我們的努力，就是一個不斷追求完美的過程。

參考：

⑻ 「JVM基礎」——垃圾回收基礎（GC相關）

當內存中的某一個對象無法找到任何引用的時候,這個對象就是一個垃圾對象。

內存泄露（memory leak），是指程序中已動態分配的堆內存由於某種原因程序未將其釋放或無法釋放，造成了內存的浪費，導致程序運行速度減慢甚至程序崩潰等嚴重後果。

STW即stop the world ，指的是JVM進行GC時會暫停所有業務線程。

給每一個對象添加一個引用計數器，t每當有新的引用時，計數器+1，引用結束後計數器-1。任何時刻計數器為0的對象都是不被引用的。

優點：
1. 引用計數演算法在回收垃圾時具有實時性。當一個對象的引用為0的時候會被直接回收，無需等待特定時間就可以釋放內存。
缺點：
1.當出現對象之間循環引用的時候，垃圾回收期無法確定這些對象是否是垃圾，因此無法回收循環引用的對象。（內存泄漏）

從GC Roots節點(起始節點)出發向下搜索，如果沒有任何引用鏈（既GC root不可達），則證明此對象不可用

tracing GC的本質是通過找出所有活對象來把其餘空間認定為「無用」，而不是找出所有死掉的對象並回收它們佔用的空間。GC roots這組引用是tracing GC的起點。要實現語義正確的tracing GC，就必須要能完整枚舉出所有的GC roots，否則就可能會漏掃描應該存活的對象，導致GC錯誤回收了這些被漏掃的活對象。

將需要清除的對象標記出來，清除掉。

標記清除演算法的實現分為兩個階段：

優點：
只對存活的對象進行標記。標記完畢後再掃描整個空間中未被標記的對象進行回收。該演算法不需要進行對象的移動，只需對不存活的對象進行處理，效率高。
缺點
因為直接回收掉了不存活對象，未對內存進行整理，因此會產生內存碎片。內存碎片較多時，當大對象進入內存空間，無法為期分配足夠的內存會提前觸發GC。

將內存一分為二，每次使用一個區域。當觸發gc時，將存活對象復制到另一區域，清除原區域。

它開始時把堆分成 一個對象 面和多個空閑面， 程序從對象面為對象分配空間，當對象滿了，基於ing演算法的垃圾 收集就從根集合（GC Roots）中掃描活動對象，並將每個 活動對象復制到空閑面(使得活動對象所佔的內存之間沒有空閑洞)，這樣空閑面變成了對象面，原來的對象面變成了空閑面，程序會在新的對象面中分配內存。

優點 ：

缺點：

標記清除演算法的優化實現，清除垃圾對象的同時壓縮空間。

該演算法標記階段和Mark-Sweep一樣，但是在完成標記之後，它不是直接清理可回收對象，而是將存活對象都向一端移動，然後再清理掉無用對象

優點：
1.因為對空間進行了整理，因此不會產生內存碎片。
缺點
1.因為掃描了兩次，並且在清除的基礎上還增加了整理，因此時間成本高。

⑼ 我的世界輸入/gc指令裡面的內存看不懂 求解

樓上說的不對
最大內存是指你給jvm虛擬機分配的最大內存 你這是不到10GB，這個數值是閥值最大值
已分配內存是只jvm虛擬機目前已經使用了多少，你這里顯示使用了3GB左右
空閑內存是指jvm虛擬機當前空閑的內存數值，就是說jvm現在用了3GB左右的內存，但是虛擬機中有2GB多是空閑的
換句話說就是
已分配內存-空閑內存=當前jvm實際使用的內存(這個內存包括頁面文件)

舉個栗子，甜甜的栗子0w0
比如開服.bat裡面寫著
-Xmx10G -Xms4G -jar bukkitcraft_1.7.2_r0.3.jar
那麼你開服之後輸入/gc或者cmd里直接打gc
就會得到這樣的數據
最大內存 10240MB
已分配內存 4096MB
空閑內存 3072MB
你可以自己試試看
空閑內存是指jvm虛擬機已分配部分的空閑內存

⑽ JVM性能調優（2） —— 內存設置和查看GC日誌

1）JVM內存分配有如下一些參數：

一般 -Xms 和 -Xmx 設置一樣的大小，-XX:MetaspaceSize 和 -XX:MaxMetaspaceSize 設置一樣的大小。-Xms 等價於 -XX:InitialHeapSize，-Xmx等價於-XX:MaxHeapSize；-Xmn等價於-XX:MaxNewSize。

2）在IDEA中可以按照如下方式設置JVM參數：

3）命令行啟動時可以按照如下格式設置：

1）設置GC參數：

可以在啟動時加上如下參數來查看GC日誌：

例如，我在IDEA中添加了如下JVM啟動參數：

啟動程序之後列印出了如下的一些日誌：

從第三行 CommandLine flags 可以得到如下的信息：

2）查看默認參數：

如果要查看JVM的默認參數，就可以通過給JVM加列印GC日誌的參數，就可以在GC日誌中看到JVM的默認參數了。

還可以在啟動參數中添加 -XX:+PrintFlagsFinal 參數，將會列印系統的所有參數，就可以看到自己配置的參數或系統的默認參數了：

3）GC日誌：

之後的日誌就是每次垃圾回收時產生的日誌，每行日誌說明了這次GC的執行情況，例如第四行GC日誌：

詳細內容如下：

2020-09-25T13:00:41.631+0800：GC發生的時間點。
4.013：系統運行多久之後發生的GC，單位秒，這里就是系統運行 4.013 秒後發生了一次GC。
GC (Allocation Failure)：說明了觸發GC的原因，這里是指對象分配失敗導致的GC。
PSYoungGen：指觸發的是年輕代的垃圾回收，使用的是 Parallel Scavenge 垃圾回收器。
419840K->20541K：對年輕代執行了一次GC，GC之前年輕代使用了 419840K，GC之後有 20541K 的對象活下來了。
(472064K)：年輕代可用空間是 472064K，即 461 M，為什麼是461M呢？因為新生代大小為 512M，Eden 區占 409.6M，兩塊 Survivor 區各占 51.2M，所以年輕代的可用空間為 Eden+1個Survivor的大小，即460.8M，約為461M。
419840K->20573K：GC前整個堆內存使用了 419840K，GC之後堆內存使用了 20573K。
(996352K)：整個堆的大小是 996352K，即 973M，其實就是年輕代的 461M + 老年代的 512 M
0.0118345 secs：本次GC耗費的時間
Times: user=0.00 sys=0.00, real=0.01 secs：本次GC耗費的時間
4）JVM退出時的GC情況：

程序結束運行後，還會列印一些日誌，就是第12行之後的日誌，這部分展示的是當前堆內存的使用情況：

詳細內容如下：