如何确定GarbageFirst回收器发生的是FullGC ?

必须出现FullGC字样才算是FUllGC，例如下图：因为内存分配失败（Allocation Failure）导致

如果不出现FullGC的字样说明它不是FUllGC，并不像Serial GC、ParallelGC的在老年代不足发生叫的FullGC。

FullGC之前日志展示经历的过程：

concurrent-root-region-scan-start:并发Root扫描

concurrent-root-region-scan-end:Root扫描完了

concurrent-mark-start:并发标记阶段(在上图箭头上一行)

FullGC

如何监控FullGC日志？

首先在启动参数上加如下参数：代表在jar包同位置实时生成回收日志

-Xloggc:gc.log

如何监控堆Dump日志？

1.启动参数配置

在线程出现OOM（Out of memory）的时候如果配置了参数则会产生当前的堆快照在dump文件中：(gc.dump也是代表与jar包同位置的快照文件)

-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=gc.dump

堆内存快照是一个 .hprof 文件，包含程序运行时堆内存的详细信息，包括对象、类、引用等，用于分析内存泄漏或对象分配问题。

2.运行时执行jmap命令

jmap -dump:format=b,file=/路径/名.hprof 进程号

说明：这个也命令是生成堆转储快照，只不过它在不触发OOM的时候人可以手动执行命令调用，但是要注意这个操作必然会带来Stop the world使JVM停顿用来抓取快照，线上请谨慎使用

案例

1.比如我这有个kafka进程（kafka运行在JVM）

2.执行jmap dump命令并下载

对这个进程执行jmap -dump:format=b,file=/data/dumptest/heap_dump.hprof 21896 命令并下载到本地进行分析

3.打开Memory Analyzer (MAT)进行分析

 

自动检测堆转储中的内存泄漏嫌疑点

4.可能遇到问题——快照文件太大，内存不够

选择合理的GC垃圾回收器

JDK9默认就是G1垃圾回收器的内存模型，但是也可以根据场景，比如CPU核心数是否够用，1、2核心的CPU在并发垃圾回收的环境下可能相差无几

在CPU核心多时，堆内存很小的情况下G1 和 ParallelGC 性能差不多，区别不大。

G1的使用：在堆内存分配大且CPU核心多于2核的才能甩开ParallelGC