Java8 默认垃圾回收器
Java 8要使用CMS(concurrent mark-sweep),那么必须显示设置,它采用的默认垃圾回收器是ParallelGC
测试代码
package codeTest;
import java.util.ArrayList;
import java.util.List;
/**
* @Description TestGC :
* @Author sr
* @Date 2021/8/29
*/
public class TestGC{
private static final int SIZE_1M = 1024 * 1024;
public static void main(String[] args) {
List<byte[]> list = new ArrayList<>();
while (true) {
list.add(new byte[SIZE_1M]);
}
}
}
验证默认垃圾回收器,添加如下配置参数
-verbose:gc -XX:+PrintGCDetails
由下图可以看出,jdk8默认垃圾回收器是ParallelGC
CMS使用(concurrent mark-sweep)并发标记清除
显示申明垃圾回收器为CMS+parNew
-XX:+UseConcMarkSweepGC -XX:+UseParNewGC
再运行以上代码可以看到现在所使用得便是CMS
堆内存大小设置 (head)
设置年轻代和老年代的大小。由于采用的CMS+ParNew。建议堆大小不要超过8G,最好6G以内,因为CMS+ParNew组合情况下发生的FGC是采用MSC算法且单线程回收,如果堆内存很大,FGC时STW(STOP THE WORLD)时间会非常恐怖。以4G举例,这时候再添加几个JVM参数。这里设置的年轻代大概是1.5G,老年代大概是2.5G。这算是一个比较合理的比例搭配。如果你的JVM参数这样搭配但是GC情况仍然不是很好,那么可能需要根据你的业务特性进行特别的调优:
-Xmx4g -Xms4g -Xmn1512m
线程栈大小设置(stack)
JDK8默认的线程栈大小为1M,有点偏大。绝大部分微服务项目是可以调整为512k,甚至256k。
-Xss512k
老年代回收阈值 (old)
既然配置的是CMS,那么如下两个参数一定要加上。因为CMS回收条件非常复杂,如果不通过CMSInitiatingOccupancyFraction和UseCMSInitiatingOccupancyOnly限制只在老年代达到75%才回收的话(这个阈值可以根据具体情况适当调整),当线上碰到一些CMS GC时,是很难搞清楚原因的:
-XX:CMSInitiatingOccupancyFraction=75
-XX:+UseCMSInitiatingOccupancyOnly
元数据空间 (Metaspace)
微服务架构,对于绝大部分应用来说,128M的元数据完全够用。不过,java8的元数据空间并不是指定多少就初始化多大的空间。而是按需扩展元数据空间。所以,我们可以设置256M。如果不设置这两个参数的话,元数据空间默认初始化只有20M出头,那么就会在应用启动过程中,Metaspace扩容发生FGC:
-XX:MaxMetaspaceSize=256m -XX:MetaspaceSize=256m
dump路径
设定如下两个参数(需要说明的是,HeapDumpPath参数指定的路径需要提前创建好,JVM没办法在生成dump文件时创建该目录),当JVM内存导致导致JVM进程退出时能自动在该目录下生成dump文件:
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/data/log/jvmdump/
GC日志
线上环境GC问题都不好排查。并且loggc所在目录(/data/log/gclog/)和dump路径一样,必须提前创建好,JVM无法自动创建该目录:
-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:/data/log/gclog/gc.log
压缩
CMS GC是并发的垃圾回收器,它采用的是标记清除算法,而不是压缩算法。意味着随着时间的推移,碎片会越来越多,JVM终究会触发内存整理这个动作。那么,什么时候整理内存碎片呢?跟下面两个参数有很大的关系。第一个参数是开启这个能力,第二个参数表示在压缩(compaction)内存之前需要发生多少次不压缩内存的FGC。CMS GC不是FGC,在CMS GC搞不定的时候(比如:concurrent mode failure),会触发完全STW但不压缩内存的FGC(假定命名为NoCompactFGC),或者触发完全STW并且压缩内存的FGC(假定命名为CompactFGC)。所以,这个参数的意思就是,连续多少次NoCompactFGC后触发CompactFGC。如果中间出现了CMS GC,那么又需要重新计数NoCompactFGC发生的次数:
-XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=0
这里给出的配置事实上是默认值,即每次CMS GC搞不定的情况下触发CompactFGC。这两个参数很不好理解,为此,笔者举几个例子,假定有3种GC方式:CMS GC,NoCompactFGC, CompactFGC(如下时yi du a):
if(should_compact){
// mark-sweep-compact
do_compaction_work(clear_all_soft_refs)
} else {
// mark-sweep
do_mark_sweep_work(clear_all_soft_refs,first_state,should_start_over);
}
NoCompactFGC就是不压缩内存的FGC,采用的是标记清除(Mark-Sweep)算法,CompactFGC是会压缩内存的FGC,采用的是标记清除压缩算法(Mark Sweep Compact),然后假设我们配置了-XX:CMSFullGCsBeforeCompaction=3,那么:
- CMS GC, NoCompactFGC, NoCompactFGC, NoCompactFGC, CompactFGC(这时候如果发生FGC就会压缩内存)
- CMS GC, NoCompactFGC, NoCompactFGC, CMS GC, NoCompactFGC(这时候如果发生FGC不会压缩内存,因为在此之前并没有连续3次NoCompactFGC)
- CMS GC, CMS GC, CMS GC, NoCompactFGC(如果前面连续发生的是CMS GC,那么接下来触发的FGC还不会压缩内存)
Example
推荐给大家一个搭配CMS时很好用的JVM参数,如下所示。
官方对该参数的说明为:A System.gc() request invokes a concurrent collection and also unloads classes during such a concurrent gc cycle (effective only when UseConcMarkSweepGC)。这句话总结如下:
- 只有在使用CMS时才有效。
- 当调用System.gc()时会用CMS这个并行垃圾回收器去进行回收(比如大量使用DirectByteBuffer进行堆外内存操作,需要FGC来回收堆外内存的场景。就可以通过该参数让本来需要FGC才能搞定的事情用CMS GC就可以搞定了)。
- 除了能唤起并行垃圾回收器,还能卸载类。
-XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses
我们配置的完整的JVM参数配置如下(此参数在一个朋友负责的一个微服务项目中运行了数年,单机并发1000+,CMS GC大概是8天左右一次):
-Xms4g -Xmx4g -Xmn1512m -server -Xss256k -XX:MetaspaceSize=256M -XX:MaxMetaspaceSize=256m -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:/data/log/gclog/gc.log -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/data/log/jvmdump/ -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:CMSInitiatingOccupancyFraction=75 -XX:+UseCMSInitiatingOccupancyOnly -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=0 -XX:+CMSClassUnloadingEnabled -XX:+TieredCompilation -XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses
如下供查看 复制从上面
----------------------------------------------------------------------------------------------
-Xms4g
-Xmx4g
-Xmn1512m
-server -Xss256k
-XX:MetaspaceSize=256M
-XX:MaxMetaspaceSize=256m
-XX:+PrintGCDetails
-XX:+PrintGCDateStamps
-Xloggc:/data/log/gclog/gc.log
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=/data/log/jvmdump/
-XX:+UseConcMarkSweepGC -XX:+UseParNewGC
-XX:CMSInitiatingOccupancyFraction=75
-XX:+UseCMSInitiatingOccupancyOnly
-XX:+UseCMSCompactAtFullCollection
-XX:CMSFullGCsBeforeCompaction=0
-XX:+CMSClassUnloadingEnabled
-XX:+TieredCompilation
-XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses
----------------------------------------------------------------------------------------------
JVM调优学习网站
可以模拟各种参数
https://opts.console.heapdump.cn/