一、 内存溢出问题的排查

1. 使用工具 - jdk自带

• jmap
• visualvm

2. 流程

1. 堆转储：
   (1) 方法一：程序运行时，采用：jmap -dump:format=b,file=d:\\data\\xxlJob.hprof 23300 进行堆文件的转储
   (2) 方法二：在内存溢出的时候，打印堆转储文件

-XX:+HeapDumpOnOutOfMemoryError           # 开启OOM时自动转储堆
-XX:HeapDumpPath=/path/to/dump/dir/       # 指定堆转储文件路径
-XX:OnOutOfMemoryError="command args"     # OOM时执行外部命令

2. 导入visualVM中
   文件->装入->选择堆转储文件

3. 分析：自定义的对象的数量、大小都不应该太大
   a. 通过大小、对象数量进行排序，查看靠前的对象是否存在自定义的对象
   b. 通过名称排序，查看自定义的对象中，哪个对象最靠前

二、gc频繁问题的排查

1. 了解堆分配的策略

a. 优先分配到年轻代
b. 大对象直接分配到老年代
c. 长期存活的对象进入老年代
d. 对象担保策略：如果年轻代的对象的总容量大于了老年代的剩余容量，需要进行一次full gc

2. 频繁minor gc

原因
（1） 内存分配过小
（2） 内存泄漏
（3） 频繁的对象创建

排查和解决方案
（1）经过mimor gc之后，对象仍旧无法被清除，导致full gc：考虑内存泄漏问题，查看是否存在内存泄漏，可以通过jmap + visualvm进行排查
（2） 如果是并发高的场景：minor gc之后，考虑eden分配过小，尝试增大内存的分配量，尤其是eden区的
（3） 如果不是高并发，内存还有急速升高的情况，可能是对象创建太过频繁，或者创建了大对象导致的
总结：分配大内存 + 排查堆转储文件，查看哪个自定义对象的占用内存较大，优化代码

3. 频繁full gc

原因
（1）minor gc分配太小，导致频繁minor gc，进而对象年龄急速增加，进入老年代
（2）full gc 分配太小，空间担保机制，使得minor gc之前，需要进行full gc
（3）内存泄漏或者大对象的创建

解决方案：
（1）首先尝试分配大内存
（2）如果不行，通过排查堆转储文件，也就是使用jmap和visualvm查看较大的自定义对象