不同的垃圾回收器 他们的日志都是完成不一样的，看懂日志是解决和发现问题的重中之重。
Parallel Scavenge + Parallel Old 日志
启动参数
-XX:+UseParallelGC -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintHeapAtGC -Xloggc:gc.log
ygc日志
fullgc日志 如下图 主要是 gc日志上多了回收老年代、元空间、GC类型变为Full GC
年轻代的total=eden+1个s区 如图中 10752+1536=12288k
GC触发原因常见的有
- Allocation Failure 年轻代中没有足够区域能够存放需要分配的数据而失败
- Ergonomics 常见于FullGc中 是因为 UseAdaptiveSizePolicy 开启了自适应调整策略而发生的GC 很正常的
- Metadata GC Threshold 常见于Full Gc 元空间不足
G1
G1有几种类型的gc，YGC (仅回收年轻代) ，Miexd GC(年轻代和部分老年代都回收 也叫混合GC)，Full GC (整堆回收 g1中一般很少出现fullgc)， 启动参数如下
-XX:+UseG1GC -XX:InitiatingHeapOccupancyPercent=40 -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintHeapAtGC -Xloggc:gc.log
MiexdGc 回收流程参考 回收流程
YGC 日志格式
Miexd GC日志格式
miexd gc日志就能完全体现出G1回收流程的几个阶段 初始标记-并发标记-最终标记-筛选回收
Full gc日志格式
Full Gc日志看起来很轻松 在G1中应该避免不要产生FullGC
CMS
cms是老年代回收器 日志格式也是分阶段打印的 具体流程可以参考 cms回收阶段流程 启动参数如下
-Xms50m -Xmx50m -XX:+UseConcMarkSweepGC -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintHeapAtGC -Xloggc:gc.log
老版的垃圾回收器如 parNew 串行不再去花太多时间研究了 一般也用不上 有更好的选择。
在线日志分析工具 https://gceasy.io/gc-index.jsp