共计 2472 个字符，预计需要花费 7 分钟才能阅读完成。
https://gitee.com/vectorx/NOT…
https://codechina.csdn.net/qq…
https://github.com/uxiahnan/N…
[TOC]
5. 剖析 GC 日志
5.1. GC 分类
针对 HotSpot VM 的实现，它外面的 GC 依照回收区域又分为两大种类型：一种是局部收集（Partial GC），一种是整堆收集（Full GC）
-
局部收集（Partial GC）：不是残缺收集整个 Java 堆的垃圾收集。其中又分为：
- 新生代收集（Minor GC / Young GC）：只是新生代（Eden / S0, S1）的垃圾收集
- 老年代收集（Major GC / Old GC）：只是老年代的垃圾收集。目前，只有 CMS GC 会有独自收集老年代的行为。<mark> 留神，很多时候 Major GC 会和 Full GC 混同应用，须要具体分辨是老年代回收还是整堆回收。</mark>
- 混合收集（Mixed GC）：收集整个新生代以及局部老年代的垃圾收集。目前，只有 G1 GC 会有这种行为
- 整堆收集（Full GC）：收集整个 java 堆和办法区的垃圾收集。
5.2. GC 日志分类
MinorGC
MinorGC（或 young GC 或 YGC）日志：
[GC (Allocation Failure) [PSYoungGen: 31744K->2192K (36864K) ] 31744K->2200K (121856K), 0.0139308 secs] [Times: user=0.05 sys=0.01, real=0.01 secs]
FullGC
[Full GC (Metadata GC Threshold) [PSYoungGen: 5104K->0K (132096K) ] [Par01dGen: 416K->5453K (50176K) ]5520K->5453K (182272K), [Metaspace: 20637K->20637K (1067008K) ], 0.0245883 secs] [Times: user=0.06 sys=0.00, real=0.02 secs]
5.3. GC 日志构造分析
透过日志看垃圾收集器
- Serial 收集器：新生代显示 “[DefNew”，即 Default New Generation
- ParNew 收集器：新生代显示 “[ParNew”，即 Parallel New Generation
- Parallel Scavenge 收集器：新生代显示 ”[PSYoungGen”，JDK1.7 应用的即 PSYoungGen
- Parallel Old 收集器：老年代显示 ”[ParoldGen”
- G1 收集器：显示”garbage-first heap“
透过日志看 GC 起因
- Allocation Failure：表明本次引起 GC 的起因是因为新生代中没有足够的区域寄存须要调配的数据
- Metadata GCThreshold：Metaspace 区不够用了
- FErgonomics：JVM 自适应调整导致的 GC
- System：调用了 System.gc() 办法
透过日志看 GC 前后状况
通过图示，咱们能够发现 GC 日志格局的法则个别都是：GC 前内存占用 ->GC 后内存占用（该区域内存总大小）
[PSYoungGen: 5986K->696K (8704K) ] 5986K->704K (9216K)- 中括号内：GC 回收前年老代堆大小，回收后大小，（年老代堆总大小）
- 括号外：GC 回收前年老代和老年代大小，回收后大小，（年老代和老年代总大小）
<mark> 留神 </mark>：Minor GC 堆内存总容量 = 9/10 年老代 + 老年代。起因是 Survivor 区只计算 from 局部，而 JVM 默认年老代中 Eden 区和 Survivor 区的比例关系，Eden:S0:S1=8:1:1。
透过日志看 GC 工夫
GC 日志中有三个工夫：user，sys 和 real
- user：过程执行用户态代码（外围之外）所应用的工夫。这是执行此过程所应用的理论 CPU 工夫，其余过程和此过程阻塞的工夫并不包含在内。在垃圾收集的状况下，示意 GC 线程执行所应用的 CPU 总工夫。
- sys：过程在内核态耗费的 CPU 工夫，即在内核执行零碎调用或期待零碎事件所应用的 CPU 工夫
- real：程序从开始到完结所用的时钟工夫。这个工夫包含其余过程应用的工夫片和过程阻塞的工夫（比方期待 I/O 实现）。对于并行 gc，这个数字应该靠近（用户工夫+零碎工夫）除以垃圾收集器应用的线程数。
因为多核的起因，个别的 GC 事件中，real time 是小于 sys time+user time 的，因为个别是多个线程并发的去做 GC，所以 real time 是要小于 sys+user time 的。如果 real>sys+user 的话，则你的利用可能存在下列问题：IO 负载十分重或 CPU 不够用。
5.4. GC 日志剖析工具
GCEasy
GCEasy 是一款在线的 GC 日志分析器，能够通过 GC 日志剖析进行内存泄露检测、GC 暂停起因剖析、JVM 配置倡议优化等性能，大多数性能是收费的。
官网地址：https://gceasy.io/
GCViewer
GCViewer 是一款离线的 GC 日志分析器，用于可视化 Java VM 选项 -verbose:gc 和 .NET 生成的数据 -Xloggc:<file>。还能够计算与垃圾回收相干的性能指标（吞吐量、累积的暂停、最长的暂停等）。当通过更改世代大小或设置初始堆大小来调整特定应用程序的垃圾回收时，此性能十分有用。
源码下载：https://github.com/chewiebug/GCViewer
运行版本下载：https://github.com/chewiebug/GCViewer/wiki/Changelog
GChisto
- 官网上没有下载的中央，须要本人从 SVN 上拉下来编译
- 不过这个工具仿佛没怎么保护了，存在不少 bug
HPjmeter
- 工具很弱小，然而只能关上由以下参数生成的 GC log，-verbose:gc -Xloggc:gc.log。增加其余参数生成的 gc.log 无奈关上
- HPjmeter 集成了以前的 HPjtune 性能，能够剖析在 HP 机器上产生的垃圾回收日志文件
