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行之后的日志，这部分展示的是当前堆内存的使用情况：

详细内容如下：