GC简介:
GC(Garbage Collection)是java中的垃圾回收机制,是Java与C++/C的主要区别之一,在使用JAVA的时候,一般不需要专门编写内存回收和垃圾清理代 码。这是因为在Java虚拟机中,存在自动内存管理和垃圾清扫机制。
什么时候GC?
什么时候发生GC?
什么时候full GC?
什么情况下会发生Full GC?
GC类型:
-
Serial GC:为单核CPU上的桌面应用设计的。使用Serial GC会明显的损耗应用的性能。
参数-XX:+UseSerialGC
就是Young区和old区都使用serial 垃圾回收算法, -
Parallel GC:Parallel GC适用于多核CPU且使用了较大内存空间的场景。Parallel GC又被称为"高吞吐GC(throughput GC)“
参数-XX:+UseParallelGC
Young区:使用Parallel scavenge 回收算法
Old 区:可以使用单线程的或者Parallel 垃圾回收算法,由 -XX:+UseParallelOldGC 来控制 -
Parallel Old GC(Parallel Compacting GC)
Parallel的GC算法是为老年代设计的。 -
Concurrent Mark & Sweep GC (or “CMS”)
低延迟GC,适用于所有应用对响应时间要求比较严格的场景。
与其他GC相比,CMS GC要求更多的内存空间和CPU资源
CMS GC默认不提供内存压缩
参数-XX:+UseConcMarkSweepGC
Young区:可以使用普通的或者parallel 垃圾回收算法,由参数 -XX:+UseParNewGC来控制
Old 区:只能使用Concurrent Mark Sweep -
Garbage First (G1) GC
G1最大的改进在于其性能表现,它比以上任何一种GC都更快速
参数:-XX:+UseG1GC
没有young/old区
不同区域用到的算法
什么是GC监控?
GC监控 指的是在运行时跟踪JVM运行GC的过程。例如,通过GC监控,我们能找出:
- 何时新生代的对象会被移动到老年代,有多少对象被移到了老年代。
- 何时stop-the-world发生以及持续时间。
- 通过GC监控,能发现JVM是否在有效的运行GC以及是否需要额外的GC调优。基于这些信息,我们可以通过优化应用或者改变GC运行方式(GC调优),从而提高应用性能
如何做GC监控?
jstat: Java Virtual Machine Statistics Monitoring Tool
在使用-gcutil选项时,会输出如下字段的信息。在做GC调优时,尤其要关注YGC, YGCT, FGC, FGCT和GCT的数据变化。
[root@hadoop1012 ~]# jstat -gcutil 1845 3000 100
S0 S1 E O M CCS YGC YGCT FGC FGCT GCT
0.00 100.00 35.86 6.50 95.92 87.40 1 0.023 0 0.000 0.023
0.00 100.00 35.86 6.50 95.92 87.40 1 0.023 0 0.000 0.023
0.00 100.00 35.86 6.50 95.92 87.40 1 0.023 0 0.000 0.023
0.00 100.00 35.86 6.50 95.92 87.40 1 0.023 0 0.000 0.023
0.00 100.00 35.86 6.50 95.92 87.40 1 0.023 0 0.000 0.023
0.00 100.00 35.86 6.50 95.92 87.40 1 0.023 0 0.000 0.023
0.00 100.00 35.86 6.50 95.92 87.40 1 0.023 0 0.000 0.023
0.00 100.00 35.86 6.50 95.92 87.40 1 0.023 0 0.000 0.023
0.00 100.00 35.86 6.50 95.92 87.40 1 0.023 0 0.000 0.023
0.00 100.00 35.86 6.50 95.92 87.40 1 0.023 0 0.000 0.023
YGC:从应用程序启动到采样时年轻代中gc次数
YGCT:从应用程序启动到采样时年轻代中gc所用时间(s)
FGC:从应用程序启动到采样时old代(全gc)gc次数
FGCT:从应用程序启动到采样时old代(全gc)gc所用时间(s)
GCT:从应用程序启动到采样时gc用的总时间(s)
新生代的GC大概需要平均时间 YGCT/YGC
老生代的GC大概需要平均时间 FGCT/FGC
在监控的里FullGC发生0次(FGC),FullGC所用时间为0ms(FGCT),YGC 1次,所用时间:YGCT为0.023s
当Full GC < 半小时/次且Fulll GC time < 1s,可认为GC工作良好。
•Minor GC执行迅速(50毫秒以内)
•Minor GC执行不频繁(间隔10秒左右一次)
•Full GC执行迅速(1秒以内)
•Full GC执行不频繁(间隔10分钟左右一次)
如不满足,则说明GC有优化的空间,但不是必须,需结合实际业务处理速度来看。
如GC进行优化,则需进行长时间的稳定性测试,同时监控GC的指标来判断GC优化的有效性。
两种监控方式:
在使用-verbosegc时还可同时指定以下附加选项:
- -XX:+PrintGCDetails 可以详细了解GC中的变化
- -XX:+PrintGCTimeStamps 可以了解这些垃圾收集发生的时间,自JVM启动以后以秒计量。
- -XX:+PrintHeapAtGC 了解堆的更详细的信息
- -XX:+PrintGCDateStamps(JDK6U4引入的选项) GC发生的时间信息
- -Xloggc:$CATALINA_BASE/logs/gc.log GC日志产生的路径
- -XX:+PrintGCApplicationStoppedTime 输出GC造成应用暂停的时间
如果只指定-verbosegc选项,则默认会同时指定-XX:+PrintGCDetails。
另外,-verbosegc的附加选项都可以组合使用。
日志输出格式说明
- 当有minor GC发生时:
[GC [<collector>:
<starting occupancy1> -> <ending occupancy1>, <pause time1> secs]
<starting occupancy3> -> <ending occupancy3>, <pause time3> secs]
- Full GC输出的例子
[Full GC [Tenured: 3485K->4095K(4096K), 0.1745373 secs] 61244K->7418K(63104K), [Perm : 10756K->10756K(12288K)], 0.1762129 secs] [Times: user=0.19 sys=0.00, real=0.19 secs]
推荐JVM的选项
先监控GC状态
后分析监控数据并决定是否需要GC调优
参考博文:https://segmentfault.com/a/1190000004369016?utm_source=sf-backlinks