gcjavacms

1、如何查看 java gc 类型

Java中的GC有哪几种类型？

参数

描述

UseSerialGC

虚拟机运行在Client模式的默认值，打开此开关参数后，
使用Serial+Serial Old收集器组合进行垃圾收集。

UseParNewGC

打开此开关参数后，使用ParNew+Serial Old收集器组合进行垃圾收集。

UseConcMarkSweepGC

打开此开关参数后，使用ParNew+cms+Serial Old收集器组合进行垃圾收集。Serial Old作为CMS收集器出现Concurrent Mode Failure的备用垃圾收集器。

UseParallelGC

虚拟机运行在Server模式的默认值，打开此开关参数后，使用Parallel Scavenge+Serial Old收集器组合进行垃圾收集。

UseParallelOldGC

打开此开关参数后，使用Parallel Scavenge+Parallel Old收集器组合进行垃圾收集。

在Java程序启动完成后，通过jps观察进程来查询到当前运行的java进程，使用
jinfo –flag UseSerialGC 进程

的方式可以定位其使用的gc策略，因为这些参数都是boolean型的常量，如果使用该种gc策略会出现＋号，否则－号。

使用-XX:+上述GC策略可以开启对应的GC策略。

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.

GC日志的离线分析
可以使用一些离线的工具来对GC日志进行分析，比如sun的gchisto( java.net/projects/gchisto)，gcviewer（ github.com/chewiebug/GCViewer ），这些都是开源的工具，用户可以直接通过版本控制工具下载其源码，进行离线分析。

下面就已gcviewer为例，简要分析一下gc日志的离线分析，gcviewer源代码工程是maven结构的，可以直接用maven进行package，这里编译的是1.34版本，本版本的快照已经上传至附件中。

需要说明的是，gcviewer支持多种参数生成的gc日志，直接通过java –jar的方式运行，加载生成的gc日志即可

2、如何查看 java gc 类型

Java中的GC有哪几种类型？

参数

描述

UseSerialGC

虚拟机运行在Client模式的默认值，打开此开关参数后，
使用Serial+Serial Old收集器组合进行垃圾收集。

UseParNewGC

打开此开关参数后，使用ParNew+Serial Old收集器组合进行垃圾收集。

UseConcMarkSweepGC

打开此开关参数后，使用ParNew+CMS+Serial Old收集器组合进行垃圾收集。Serial Old作为CMS收集器出现Concurrent Mode Failure的备用垃圾收集器。

UseParallelGC

虚拟机运行在Server模式的默认值，打开此开关参数后，使用Parallel Scavenge+Serial Old收集器组合进行垃圾收集。

UseParallelOldGC

打开此开关参数后，使用Parallel Scavenge+Parallel Old收集器组合进行垃圾收集。

在Java程序启动完成后，通过jps观察进程来查询到当前运行的java进程，使用
jinfo –flag UseSerialGC 进程

的方式可以定位其使用的gc策略，因为这些参数都是boolean型的常量，如果使用该种gc策略会出现＋号，否则－号。

使用-XX:+上述GC策略可以开启对应的GC策略。

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.

GC日志的离线分析
可以使用一些离线的工具来对GC日志进行分析，比如sun的gchisto( https://java.net/projects/gchisto)，gcviewer（ https://github.com/chewiebug/GCViewer ），这些都是开源的工具，用户可以直接通过版本控制工具下载其源码，进行离线分析。

下面就已gcviewer为例，简要分析一下gc日志的离线分析，gcviewer源代码工程是maven结构的，可以直接用maven进行package，这里编译的是1.34版本，本版本的快照已经上传至附件中。

需要说明的是，gcviewer支持多种参数生成的gc日志，直接通过java –jar的方式运行，加载生成的gc日志即可：

3、java的gc为什么要分代？

假如哈，现在的计算机能做的1ms扫描完所有live object，10ms完成live set的整理（compaction），大多数java应用都会觉得“这没毛病了”，那么，现在Hotspot JVM设计的那几套GC算法组合确实就没意义了。下面，再继续谈一哈GC的哲学。类似分布式系统的CAP theorem，GC算法设计也是有这个3取2的三角组合的：即延时（latency）、吞吐（throughput）和内存消耗（footprint）。基本的设计原理就是footprint为有限值的条件下，我们再在latency和throughput上挑一个优化，比如Hotspot JVM实现中，CMS算法主攻latency，Parallel GC 主攻throughput，G1 GC较关注latency同时兼顾一点throughput。来来来，我们开个脑洞：我们能不能放弃或减弱“footprint为有限值”这个条件。嗯～比如，一个应用1小时使用100G memory（暂时不管这100G会产生多少垃圾），服务器24小时会重启一次，那么，每次重启前java应用需要使用的内存会达到2,400G。也就是说，在这个case中，java能使用的内存如果能大于2,400G，我们根本就是不需要任何GC算法，not to mention 什么分代了；“java的gc为什么要分代”的哲学又是啥。我认为，是熵增原理 和 80/20法则。

4、问一个java GC CMS 的问题

看一下java的官方网站

5、cms垃圾回收算法在gc过程中的哪个阶段会暂停应用线程

GC在java中是垃圾回收机制，当你创建一个对象时，它就开始跟踪，当对象“可到达”时，就自动回收，也可以手动调用，但一般不推荐使用

6、cms gc过程中哪几个阶段暂停应用程序

问题解决：中间调整过几次，先搞了几台机器做了验证，后来逐步推广的。
1、调大heap区，由原来的4g，调整到5g，young区的大小不变，还是2g，这时候old区就由2g变为3g了（这样保证old区有足够的空间）；
2、设置-XX：UseCMSInitiatingOccupancyOnly，其实这个不关这个问题，只是发现半夜CMS进行的有点频繁，就禁止掉了悲观策略；
3、设置CMS区回收的比例，从80%调整到75%，让old区尽早的进行，有足够的空间剩余；

为什么要有GC（垃圾回收）？

JVM通过GC来回收堆和方法区中的内存，GC的基本原理就是找到程序中不再被使用的对象，然后回收掉这些对象占用的内存。