*Minor gc 和 full Gc

minor gc 

• 对新生代进行gc，比较频繁，因为大部分对象的生命周期都比较短，在新生代回收性能消费小；
• 当Eden区空间不足的时候，就会触发minor gc

full gc 

• 全堆范围的gc，默认堆空间使用达到80%的时候会触发full gc ，
• 老年代空间不足，永久代空间不足，调system.gc()，minor 是的悲观策略，或者 jmap -dump：live 时都会触发full gc

Minor gc 过程

• 把在Eden去和SurvivorFrom区中存活的对象复制到SurvivorTo。如果某个对象的年龄达到老年代年龄就复制到老年代（ 年龄15 XX：MaxTenuringThreshold 来设置），同时把对象的年龄加1；如果survivorTo的空间不够用或者是大对象，则直接复制到老年代
• 清空Eden和SurvivorFrom中的对象
• 将SurvivorTo和SurvivorFrom互换，原来的SurvivorTo变成下一次Minor gc 扫描的对象

年轻代迁移到老年代的场景

• 在Eden 或者 SurvivorFrom 中的对象的年龄达到限制，默认是15，也就是部分对象会在From和To中来回复制15次。可以通过参数-XX：MaxTenuringThreshold来控制。
• 新建的对象 是大对象，如果老年代分配不下 就做一次major gc
• minor gc 后，survivorTo仍放不下，就放到老年代
• 动态年龄判断，大于等于某个年龄的对象超过survivor空间的一半，把这些对象迁移到老年代

Full Gc 怎么排查

首先full gc 频繁说明老年代快满了，首先要排查相关参数设置，确认问题原因：

• 如果一次full gc后 剩余对象不多，说明Eden区设置的小，导致minor gc 比较多，很多生命周期短的对象进入到老年代；
• 如果一次 full gc 后，老年代的回收率不大，说明老年代分配小了。
• 有很多短期存活的大对象，就是程序问题

导出内存dump文件（dump时会stop the Word）

jmap -F -dump:live,file=jmap.hprof [PID] 

把dump文件下载到本地，

scp local_file remote_ip:remote_folder  

通过jdk自带的 jvisualvm 工具分析

或者用mat来分析，直接出结果可能有 see statckTrace。

 

也可以通过设置参数 -XX：+HeapDumpOnOutOfMemoryError， oom时自动dump文件，然后照旧用快照分析。

 

把full gc 和没发生 full gc 的dump文件都下载下来

 

CPU 100% 怎么排查

• 首先 top一下 查看cup占用情况，看到占用最高的进程 PID
• top -Hp [pid] 看一下这个进程下面的各个线程运行情况 ,找到占用CPU最高的线程id
• 然后 jstack 查线程id 为啥会高，这里需要转16进制。
  • 如果是VM Thread，可能就是 gc线程
    • 如果是gc线程的话 jstat -gc 看一下gc的情况，如果次数过高就排查full gc 频繁原因了。
  • 死锁
    • jstack可以帮忙确认
  • 某个接口偶尔耗时较高，可以通过压测验证