java gc 时间长_【Java】GC 时间过长的问题处理思考

零 前述

本文以 G1 作为主视角来做对策分析。

jdk8 中将 GC 调整为 G1 -XX:+UseG1GC

一 从编码层面来说

1 减少对象的创建频率

尽量复用以前存在的对象，减少对象创建，那么就能减少 gc 的频率。

方法有：

单例模式

享元模式

静态对象

枚举类

对象池技术

用 StringBuilder 和 IntegerCache 等方法去代替直接创建对象

2 从根本上减少堆内存的使用

使用其它内存方式代替堆内存。当一个对象的使用生命周期被囊括在栈的生命周期内，此时 jvm 会通过逃逸分析判断该对象不需要在堆上分配内存，只需要创建在栈内存中就可以了。

栈内存是没有 gc 的，等栈的生命周期结束就被全部删除了

注意设置好 jvm 栈内存的大小，不要 OOM

也可以使用 Unsafe 去操作元空间的内存，但是要注意控制手动释放

涉及参数设置：

设置栈内存的大小，单位 kb -Xss:1024 开启逃逸分析，默认就是开启的 -XX:+DoEscapeAnalysis

3 小对象代替大对象

小对象对于 jvm 来说，是会直接创建在 eden 区的，但是大对象则会直接被分配在老年代。老年代比 eden 大很多，gc 起来更加费力。

默认情况下，只要 eden 区有足够的连续空间，不论多大的对象都会分配在 eden 区，这会导致 eden 区可能在短期内存在内存“碎片”，所以可以设置好 jvm 对大对象定义的阈值

尽量拆分大对象

如果确实有大对象，那么就尽量使用 part 1 中说到的方法，让它存在的时间长一些

如果确实有大对象且朝生夕死，那么尽量使用 part 2 中说到的方法，且注意设置好 jvm 栈对大对象的定义

涉及参数设置：

超过这个数 kb 大小的对象会被直接分配在老年代，默认值为无~~~~限 -XX:PretenureSizeThreshold=1000

二 从 jvm 层面来说

1 合理分配堆内存区的大小

增加 eden 区的大小，减少 full gc 的次数。

涉及参数设置：

设置新生代的大小，单位 kb -Xmn:1024 设置年轻代占堆内存的最小比例，单位 % -XX:G1NewSizePercent=5 设置年轻代占堆内存的最大比例，单位 % -XX:G1MaxNewSizePercent=60

2 设置最大停顿时间

注意也别设置的太小，不然会因为回收时间不足而 OOM。

涉及参数设置：

设置最大 stw 时间，单位 ms -XX:MaxGCPauseMillis=200

3 关闭检测

如果 gc 时间占用执行时间过长，也会报出 OOM，可以关闭这个选项。

注意，如果确实存在 gc 速度不够的问题，依然会出现 OOM 的，只是关闭了告警而已。

涉及参数设置：

关闭 gc 时间检测 -XX:-UseGCOverheadLimit

4 增加并行线程数

stw 时期的工作线程数。

涉及参数设置：

在 64 线程的 x86 CPU 上，如果用户未指定 ParallelGCThreads 的值，则默认的计算方式为： ParallelGCThreads = 8 + (64 - 8) * (5/8) = 8 + 35 = 43。 并行线程数 -XX:ParallelGCThreads=10

5 增加并发线程数

非 stw 时期的工作线程数。

涉及参数设置：

默认： ConcGCThreads = ParallelGCThreads / 4。 并发线程数 -XX:ParallelGCThreads=10

三 排查

1 打印信息

gc 日志是排查最重要的手段。

涉及参数设置：

打印 gc 日志 -XX:+PrintGC 打印 gc 详细日志 -XX:+PrintGCDetails 打印 gc 的日期时间 -XX:+PrintGCDateStamps 打印应用停留时间 -XX:+PrintGCApplicationStoppedTime 老年代分布 -XX:+PrintTenuringDistribution

2 OOM 日志打印

如果出现 OOM，会需要打印 heap 文件。

涉及参数设置：

打印 heap 文件 -XX:+HeapDumpOnOutOfMemoryError heap 文件的地址 -XX:HeapDumpPath=/path/heap/dump

============

未完待续，想到补充。