jvm 垃圾回收篇
jvm垃圾回收
了解垃圾回收
1.内存泄漏
内存泄漏指 不在使用的对象没有进行回收
例如cpp-new-delete过去
java特性-对象自动回收-就减少内存泄漏
2.java的内存管理
java-引入了自动回收
通过垃圾回收器对不在使用的对象进行回收-主要是对堆上的内存进行回收
垃圾回收的作用

3.方法区的回收选择
那么垃圾回收器需要负责对哪些部分的内存进行回收呢?
首先是线程不共享的部分,都是伴随着线程的创建而创建,线程的销毁而销毁。
–再不死线程内的资源-就需要回收
方法除外-方外会自动将开辟的空间置空循环使用
方法区中能回收的内容主要就是不再使用的类。
ps:方法区存储着类信息-一个从来不使用的类就可以被注销了
回收三大条件
1、此类所有实例对象都已经被回收,在堆中不存在任何该类的实例对象以及子类对象
2、加载该类的类加载器已经被回收
3、该类对应的 java.lang.Class 对象没有在任何地方被引用。
1 | |
如上
死循环-本质就是jmp跳-所以的数据的指向-会在下一次循环被置空 满足回收条件
那么类卸载主要用在什么场景下呢?
开发中此类场景一般很少出现,主要在如 OSGi、JSP 的热部署等应用场景中。
每个jsp文件对应一个唯一的类加载器,当一个jsp文件修改了,就直接卸载这个jsp类加载器。重新创建类加载器,重新加载jsp文件。
对象回收判断算法
1.可达分析算法
Java使用的是可达性分析算法来判断对象是否可以被回收。可达性分析将对象分为两类:垃圾回收的根对象(GC Root)和普通对象,对象与对象之间存在引用关系。
案例
下图中A到B再到C和D,形成了一个引用链,可达性分析算法指的是如果从某个到GC Root对象是可达的,对象就不可被回收。

哪些对象被称之为GC Root对象呢?
- 线程Thread对象,引用线程栈帧中的方法参数、局部变量等。
- 系统类加载器加载的java.lang.Class对象,引用类中的静态变量。

监视器对象,用来保存同步锁synchronized关键字持有的对象。

本地方法调用时使用的全局对象。
GC root查看
通过arthas和eclipse Memory Analyzer (MAT) 工具可以查看GC Root,MAT工具是eclipse推出的Java堆内存检测工具。具体操作步骤如下:
1、使用arthas的heapdump命令将堆内存快照保存到本地磁盘中。
2、使用MAT工具打开堆内存快照文件。
3、选择GC Roots功能查看所有的GC Root。


2.引用记数法
引用计数法会为每个对象维护一个引用计数器,当对象被引用时加1,取消引用时减1。
比如下图中,对象A的计数器初始为0,局部变量a1对它引用之后,计数器加1就变成了1。同样A对B产生了引用,B的计数器也是1。

引用计数法的优点是实现简单,C++中的智能指针就采用了引用计数法,但是它也存在缺点,主要有两点:
1.每次引用和取消引用都需要维护计数器,对系统性能会有一定的影响
2.存在循环引用问题,所谓循环引用就是当A引用B,B同时引用A时会出现对象无法回收的问题。
循环引用问题探究
由于A和B之间存在互相引用,所以计数器都为1,两个对象都不能被回收。但是由于没有局部变量对这两个代码产生引用,代码中已经无法访问到这两个对象,理应可以被回收。

Java并未采用该计数法
对象引用探究
1.软引用
软引用相对于强引用是一种比较弱的引用关系,如果一个对象只有软引用关联到它,当程序内存不足时,就会将软引用中的数据进行回收。
如下图中,对象A被GC Root对象强引用了,同时我们创建了一个软引用SoftReference对象(它本身也是一个对象),软引用对象中引用了对象A。

接下来强引用被去掉之后,对象A暂时还是处于不可回收状态,因为有软引用存在并且内存还够用。

如果内存出现不够用的情况,对象A就处于可回收状态,可以被垃圾回收器回收。

作用
缓存-当内存够用提供快速访问 内存不够用就清理掉-不影响操作
软引用对象本身,也需要被强引用,否则软引用对象也会被回收掉。

代码案例
软引用的执行过程如下:
1.将对象使用软引用包装起来,new SoftReference<对象类型>(对象)。
2.内存不足时,虚拟机尝试进行垃圾回收。
3.如果垃圾回收仍不能解决内存不足的问题,回收软引用中的对象。
4.如果依然内存不足,抛出OutOfMemory异常。
1 | |
softReference怎么回收呢
1、软引用创建时,通过构造器传入引用队列
2、在软引用中包含的对象被回收时,该软引用对象会被放入引用队列
3、通过代码遍历引用队列,将SoftReference的强引用删除
代码
1 | |
2.弱引用
弱引用的整体机制和软引用基本一致,区别在于弱引用包含的对象在垃圾回收时,不管内存够不够都会直接被回收。在JDK 1.2版之后提供了WeakReference类来实现弱引用,弱引用主要在ThreadLocal中使用。
1 | |
3.虚引用 终结器引用
虚引用(也叫幽灵引用)是一种特殊的引用类型,它的作用是:当对象被垃圾回收器回收时,能够收到通知。但不能通过虚引用访问到对象本身。虚引用常用于直接内存的管理,帮助垃圾回收器及时知道内存中不再使用的对象,以便回收内存。在Java中,虚引用是通过
PhantomReference类实现的。终结器引用 是一种在对象准备被垃圾回收时,能够执行特殊操作的引用类型。当对象即将被回收时,终结器引用会把对象放入一个叫做“引用队列”的地方。稍后,由一个专门的线程(
FinalizerThread)从队列中取出这些对象,并执行它们的finalize方法。在这个方法中,可以做一些清理工作,例如释放资源。但是,不推荐在finalize方法中使用强引用来重新引用对象,因为这可能导致内存泄漏。
1 | |
垃圾回收算法
对哪些对象需要回收进行标记的算法
1.算法历史

2.算法效率探究
Java垃圾回收过程会通过单独的GC线程来完成,但是不管使用哪一种GC算法,都会有部分阶段需要停止所有的用户线程 停止时间就是STW

为什么一定有STW
在GC过程中,所有的应用程序线程都会被暂停,直到GC完成。这个机制的出现主要是为了确保垃圾回收器能够在不被其他线程干扰的情况下,对堆内存进行操作。
1.内存的安全操作
- 确保一致性
- 对象的引用清理
- 避免内存泄漏和误回收
- JVM的一致性要求
1.吞吐量
吞吐量指的是 CPU 用于执行用户代码的时间与 CPU 总执行时间的比值,即吞吐量 = 执行用户代码时间 /(执行用户代码时间 + GC时间)。吞吐量数值越高,垃圾回收的效率就越高
2.最大暂停时间
用户进行GC的最大时间
3.堆使用效率
不同垃圾回收算法,对堆内存的使用方式是不同的。
1.标记内存-可以使用整个堆内存
2.复制算法 每次只能使用一般内存
3.标记清除算法

1.标记阶段,将所有存活的对象进行标记。Java中使用可达性分析算法,从GC Root开始通过引用链遍历出所有存活对象。
2.清除阶段,从内存中删除没有被标记也就是非存活对象。
优点
优点:实现简单,只需要在第一阶段给每个对象维护标志位,第二阶段删除对象即可。
缺点
1.碎片化问题
由于内存是连续的,所以在对象被删除之后,内存中会出现很多细小的可用内存单元。如果我们需要的是一个比较大的空间,很有可能这些内存单元的大小过小无法进行分配。
2.分配速度慢
由于内存碎片的存在,需要维护一个空闲链表,极有可能发生每次需要遍历到链表的最后才能获得合适的内存空间。
我们需要用一个链表来维护,哪些空间可以分配对象,很有可能需要遍历这个链表到最后,才能发现这块空间足够我们去创建一个对象。
4.复制算法

优点:
- 吞吐量高,复制算法只需要遍历一次存活对象复制到To空间即可,比标记-整理算法少了一次遍历的过程,因而性能较好,但是不如标记-清除算法,因为标记清除算法不需要进行对象的移动
- 不会发生碎片化,复制算法在复制之后就会将对象按顺序放入To空间中,所以对象以外的区域都是可用空间,不存在碎片化内存空间。
缺点:
内存使用效率低,每次只能让一半的内存空间来为创建对象使用。
流程
1.准备两块空间From空间和To空间,每次在对象分配阶段,只能使用其中一块空间(From空间)。–一半内存消耗
对象A首先分配在From空间:
2.在垃圾回收GC阶段,将From中存活对象复制到To空间。– 对象转移
在垃圾回收阶段,如果对象A存活,就将其复制到To空间。然后将From空间直接清空。
3.将两块空间的From和To名字互换。
接下来将两块空间的名称互换,下次依然在From空间上创建对象。
5.标记整理算法

标记整理算法也叫标记压缩算法,是对标记清理算法中容易产生内存碎片问题的一种解决方案。
优缺点
优点:
- 内存使用效率高,整个堆内存都可以使用,不会像复制算法只能使用半个堆内存
- 不会发生碎片化,在整理阶段可以将对象往内存的一侧进行移动,剩下的空间都是可以分配对象的有效空间
缺点:
整理阶段的效率不高
核心思想分为两个阶段:
1.标记阶段,将所有存活的对象进行标记。Java中使用可达性分析算法,从GC Root开始通过引用链遍历出所有存活对象。
2.整理阶段,将存活对象移动到堆的一端。清理掉存活对象的内存空间。-堆的移动

分代垃圾回收思想
现代优秀的垃圾回收算法,会将上述描述的垃圾回收算法组合进行使用,其中应用最广的就是分代垃圾回收算法(Generational GC)。
特色分区
分代垃圾回收将整个内存区域划分为年轻代和老年代:


Eden + survivor 这两块区域组成了年轻代。
tenured_gen指的是晋升区域,其实就是老年代。
虚拟机参数
| 参数名 | 参数含义 | 示例 |
|---|---|---|
| -Xms | 设置堆的最小和初始大小,必须是1024倍数且大于1MB | 比如初始大小6MB的写法: -Xms6291456 -Xms6144k -Xms6m |
| -Xmx | 设置最大堆的大小,必须是1024倍数且大于2MB | 比如最大堆80 MB的写法: -Xmx83886080 -Xmx81920k -Xmx80m |
| -Xmn | 新生代的大小 | 新生代256 MB的写法: -Xmn256m -Xmn262144k -Xmn268435456 |
| -XX:SurvivorRatio | 伊甸园区和幸存区的比例,默认为8 新生代1g内存,伊甸园区800MB,S0和S1各100MB | 比例调整为4的写法:-XX:SurvivorRatio=4 |
| -XX:+PrintGCDetailsverbose:gc | 打印GC日志 | 无 |
———算法垃圾回收流程、
1、分代回收时,创建出来的对象,首先会被放入Eden伊甸园区。
2、随着对象在Eden区越来越多,如果Eden区满,新创建的对象已经无法放入,就会触发年轻代的GC,称为Minor GC或者Young GC。
Minor GC会把需要eden中和From需要回收的对象回收,把没有回收的对象放入To区。

3、接下来,S0会变成To区,S1变成From区。当eden区满时再往里放入对象,依然会发生Minor GC。

此时会回收eden区和S1(from)中的对象,并把eden和from区中剩余的对象放入S0。
注意:每次Minor GC中都会为对象记录他的年龄,初始值为0,每次GC完加1。

4、如果Minor GC后对象的年龄达到阈值(最大15,默认值和垃圾回收器有关),对象就会被晋升至老年代。


当老年代中空间不足,无法放入新的对象时,先尝试minor gc如果还是不足,就会触发Full GC,Full GC会对整个堆进行垃圾回收。
如果Full GC依然无法回收掉老年代的对象,那么当对象继续放入老年代时,就会抛出Out Of Memory异常。

1 | |
为什么分区
为什么分代GC算法要把堆分成年轻代和老年代?首先我们要知道堆内存中对象的特性:
- 系统中的大部分对象,都是创建出来之后很快就不再使用可以被回收,比如用户获取订单数据,订单数据返回给用户之后就可以释放了。
- 老年代中会存放长期存活的对象,比如Spring的大部分bean对象,在程序启动之后就不会被回收了。
- 在虚拟机的默认设置中,新生代大小要远小于老年代的大小。
减少gc时间-老年代的一般都是不会被释放掉的
分代GC算法将堆分成年轻代和老年代主要原因有:
1、可以通过调整年轻代和老年代的比例来适应不同类型的应用程序,提高内存的利用率和性能。
2、新生代和老年代使用不同的垃圾回收算法,新生代一般选择复制算法,老年代可以选择标记-清除和标记-整理算法,由程序员来选择灵活度较高。
3、分代的设计中允许只回收新生代(minor gc),如果能满足对象分配的要求就不需要对整个堆进行回收(full gc),STW时间就会减少。
垃圾回收器
垃圾回收器是垃圾回收算法的具体实现。
垃圾回收器分为年轻代和老年代,除了G1之外其他垃圾回收器必须成对组合进行使用。
具体的关系图如下:


不同的垃圾回收器设计的目标是不同的,如下图所示:

吞吐量降低-但是由于内存多频繁的fullgc-也是并行-不会导致串行-所有tws还是低
1.Serial-serial old 单线程
1.年轻代组合
Serial是是一种单线程串行回收年轻代的垃圾回收器。

回收算法: 复制算法
优点
单CPU处理器下吞吐量非常出色
缺点
多CPU下吞吐量不如其他垃圾回收器,堆如果偏大会让用户线程处于长时间的等待
适用场景
Java编写的客户端程序或者硬件配置有限的场景
老年代 SerialOld垃圾回收器
SerialOld是Serial垃圾回收器的老年代版本,采用单线程串行回收
-XX:+UseSerialGC 新生代、老年代都使用串行回收器。

算法 标记整理算法
优点
单CPU处理器下吞吐量非常出色
缺点
多CPU下吞吐量不如其他垃圾回收器,堆如果偏大会让用户线程处于长时间的等待
适用场景
与Serial垃圾回收器搭配使用,或者在CMS特殊情况下使用
2.parNew-cms 年轻并发 老并行
1.年轻代parNew
ParNew垃圾回收器本质上是对Serial在多CPU下的优化,使用多线程进行垃圾回收
-XX:+UseParNewGC 新生代使用ParNew回收器, 老年代使用串行回收器

复制算法
优点
多CPU处理器下停顿时间较短
缺点
吞吐量和停顿时间不如G1,所以在JDK9之后不建议使用
适用场景
JDK8及之前的版本中,与CMS老年代垃圾回收器搭配使用
2.老年代 cms
CMS垃圾回收器关注的是系统的暂停时间,允许用户线程和垃圾回收线程在某些步骤中同时执行,减少了用户线程的等待时间。
参数:XX:+UseConcMarkSweepGC

老年代
标记清除算法
优点
系统由于垃圾回收出现的停顿时间较短,用户体验好
缺点
1、内存碎片问题
2、退化问题
3、浮动垃圾问题
适用场景
大型的互联网系统中用户请求数据量大、频率高的场景,比如订单接口、商品接口等
CMS执行步骤:
1.初始标记,用极短的时间标记出GC Roots能直接关联到的对象。
2.并发标记, 标记所有的对象,用户线程不需要暂停。
3.重新标记,由于并发标记阶段有些对象会发生了变化,存在错标、漏标等情况,需要重新标记。
4.并发清理,清理死亡的对象,用户线程不需要暂停。
缺点:
1、CMS使用了标记-清除算法,在垃圾收集结束之后会出现大量的内存碎片,CMS会在Full GC时进行碎片的整理。这样会导致用户线程暂停,可以使用-XX:CMSFullGCsBeforeCompaction=N 参数(默认0)调整N次Full GC之后再整理。
2.、无法处理在并发清理过程中产生的“浮动垃圾”,不能做到完全的垃圾回收。
3、如果老年代内存不足无法分配对象,CMS就会退化成Serial Old单线程回收老年代。
并发线程数:
在CMS中并发阶段运行时的线程数可以通过-XX:ConcGCThreads参数设置,默认值为0,由系统计算得出。
计算公式为(-XX:ParallelGCThreads定义的线程数 + 3) / 4, ParallelGCThreads是STW停顿之后的并行线程数
ParallelGCThreads是由处理器核数决定的:
1、当cpu核数小于8时,ParallelGCThreads = CPU核数
2、否则 ParallelGCThreads = 8 + (CPU核数 – 8 )*5/8
我的电脑上逻辑处理器有12个,所以ParallelGCThreads = 8 + (12 - 8)* 5/8 = 10,ConcGCThreads = (-XX:ParallelGCThreads定义的线程数 + 3) / 4 = (10 + 3) / 4 = 3

最终可以得到这张图:

并发标记和并发清理阶段,会使用3个线程并行处理。重新标记阶段会使用10个线程处理。
由于CPU的核心数有限,并发阶段会影响用户线程执行的性能。

3.Parallel parallel old 年轻并发(自动调整堆大小) 老年并发
1.年轻代
Parallel Scavenge是JDK8默认的年轻代垃圾回收器,多线程并行回收,关注的是系统的吞吐量。具备自动调整堆内存大小的特点。

复制算法
优点
吞吐量高,而且手动可控。为了提高吞吐量,虚拟机会动态调整堆的参数
缺点
不能保证单次的停顿时间
适用场景
后台任务,不需要与用户交互,并且容易产生大量的对象。比如:大数据的处理,大文件导出
常用参数:
Parallel Scavenge允许手动设置最大暂停时间和吞吐量。Oracle官方建议在使用这个组合时,不要设置堆内存的最大值,垃圾回收器会根据最大暂停时间和吞吐量自动调整内存大小。
- 最大暂停时间,
-XX:MaxGCPauseMillis=n设置每次垃圾回收时的最大停顿毫秒数 - 吞吐量,
-XX:GCTimeRatio=n设置吞吐量为n(用户线程执行时间 = n/n + 1) - 自动调整内存大小,
-XX:+UseAdaptiveSizePolicy设置可以让垃圾回收器根据吞吐量和最大停顿的毫秒数自动调整内存大小
老年代
arallel Old是为Parallel Scavenge收集器设计的老年代版本,利用多线程并发收集。
参数: -XX:+UseParallelGC 或
-XX:+UseParallelOldGC可以使用Parallel Scavenge + Parallel Old这种组合。

回收年代和算法:
老年代
标记-整理算法
优点
并发收集,在多核CPU下效率较高
缺点
暂停时间会比较长
适用场景
与Parallel Scavenge配套使用
g1垃圾回收期
1.g1介绍
JDK9之后默认的垃圾回收器是G1(Garbage First)垃圾回收器。
Parallel Scavenge关注吞吐量,允许用户设置最大暂停时间 ,但是会减少年轻代可用空间的大小。CMS关注暂停时间,但是吞吐量方面会下降。
G1设计目标就是将上述两种垃圾回收器的优点融合:
1.支持巨大的堆空间回收,并有较高的吞吐量。
2.支持多CPU并行垃圾回收。
3.允许用户设置最大暂停时间。
JDK9之后强烈建议使用G1垃圾回收器。
2.g1空间设计
之前都分新时代和老年代区-从内存逻辑上看还是连续的
G1的整个堆会被划分成多个大小相等的区域,称之为区Region,区域不要求是连续的。分为Eden、Survivor、Old区。
Region的大小通过堆空间大小/2048计算得到,也可以通过参数-XX:G1HeapRegionSize=32m指定(其中32m指定region大小为32M),Region size必须是2的指数幂,取值范围从1M到32M。

G1垃圾回收有两种方式:
1、年轻代回收(Young GC)
2、混合回收(Mixed GC)
3.G1回收触发
年轻代回收(Young GC),回收Eden区和Survivor区中不用的对象。会导致STW,G1中可以通过参数
-XX:MaxGCPauseMillis=n(默认200) 设置每次垃圾回收时的最大暂停时间毫秒数,G1垃圾回收器会尽可能地保证暂停时间。
1、新创建的对象会存放在Eden区。当G1判断年轻代区不足(max默认60%),无法分配对象时需要回收时会执行Young GC。

2、标记出Eden和Survivor区域中的存活对象,
3、根据配置的最大暂停时间选择某些区域将存活对象复制到一个新的Survivor区中(年龄+1),清空这些区域。
1 | |
4、后续Young GC时与之前相同,只不过Survivor区中存活对象会被搬运到另一个Survivor区。

5、当某个存活对象的年龄到达阈值(默认15),将被放入老年代。

6、部分对象如果大小超过Region的一半,会直接放入老年代,这类老年代被称为Humongous区。比如堆内存是4G,每个Region是2M,只要一个大对象超过了1M就被放入Humongous区,如果对象过大会横跨多个Region。(HUmongous)

7、多次回收之后,会出现很多Old老年代区,此时总堆占有率达到阈值时
(-XX:InitiatingHeapOccupancyPercent默认45%)会触发混合回收MixedGC。回收所有年轻代和部分老年代的对象以及大对象区。采用复制算法来完成。


4.G1回收方法
混合回收分为:初始标记(initial mark)、并发标记(concurrent mark)、最终标记(remark或者Finalize Marking)、并发清理(cleanup)
G1对老年代的清理会选择存活度最低的区域来进行回收,这样可以保证回收效率最高,这也是G1(Garbage first)名称的由来。

最后清理阶段使用复制算法,不会产生内存碎片。

注意:如果清理过程中发现没有足够的空Region存放转移的对象,会出现Full GC。单线程执行标记-整理算法,此时会导致用户线程的暂停。所以尽量保证应该用的堆内存有一定多余的空间。

5.使用g1
参数1: -XX:+UseG1GC 打开G1的开关,JDK9之后默认不需要打开
参数2:-XX:MaxGCPauseMillis=毫秒值 最大暂停的时
回收年代和算法:
年轻代+老年代
复制算法
优点
对比较大的堆如超过6G的堆回收时,延迟可控
不会产生内存碎片
并发标记的SATB算法效率高
缺点
JDK8之前还不够成熟
适用场景
JDK8最新版本、JDK9之后建议默认使用
1 | |
每个region大小为2m,一共有84个young区,26个幸存者区。

初始标记花了0.0478秒。

并发标记总共耗时10ms,不会产生STW。

Shenandoah GC Stw
Shenandoah 是由Red Hat开发的一款低延迟的垃圾收集器,Shenandoah 并发执行大部分 GC 工作,包括并发的整理,堆大小对STW的时间基本没有影响。

Shenandoah只包含在OpenJDK中
下载地址:https://builds.shipilev.net/openjdk-jdk-shenandoah/
添加参数,运行Java程序。
-XX:+UseShenandoahGC 开启Shenandoah GC
-Xlog:gc 打印GC日志
测试结果:

Shenandoah GC对小对象的GC停顿很短,但是大对象效果不佳。
zGC
1.zgc介绍
ZGC 是一种可扩展的低延迟垃圾回收器。ZGC 在垃圾回收过程中,STW的时间不会超过一毫秒,适合需要低延迟的应用。支持几百兆到16TB 的堆大小,堆大小对STW的时间基本没有影响。
ZGC降低了停顿时间,能降低接口的最大耗时,提升用户体验。但是吞吐量不佳,所以如果Java服务比较关注QPS(每秒的查询次数)那么G1是比较不错的选择。

2.zgc版本更迭

3.zgc使用
OracleJDK和OpenJDK中都支持ZGC,阿里的DragonWell龙井JDK也支持ZGC但属于其自行对OpenJDK 11的ZGC进行优化的版本。
建议使用JDK17之后的版本,延迟较低同时无需手动配置并行线程数。
分代 ZGC添加如下参数启用 -XX:+UseZGC -XX:+ZGenerational
非分代 ZGC通过命令行选项启用 -XX:+UseZGC

4.zgc环境
ZGC在设计上做到了自适应,根据运行情况自动调整参数,让用户手动配置的参数最少化。
-Xmx 值 最大堆内存大小
这是ZGC最重要的一个参数,必须设置。ZGC在运行过程中会使用一部分内存用来处理垃圾回收,所以尽量保证堆中有足够的空间。设置多少值取决于对象分配的速度,根据测试情况来决定。
-XX:SoftMaxHeapSize=值
ZGC会尽量保证堆内存小于该值,这样在内存靠近这个值时会尽早地进行垃圾回收,但是依然有可能会超过该值。
例如,-Xmx5g -XX:SoftMaxHeapSize=4g 这个参数设置,ZGC会尽量保证堆内存小于4GB,最多不会超过5GB。

ZGC整体表现还是非常不错的,分代也让ZGC的停顿时间有更好的表现。
5.zgc调优
ZGC 中可以使用Linux的Huge Page大页技术优化性能,提升吞吐量、降低延迟。
注意:安装过程需要 root 权限,所以ZGC默认没有开启此功能。
操作步骤:
1、计算所需页数,Linux x86架构中大页大小为2MB,根据所需堆内存的大小估算大页数量。比如堆空间需要16G,预留2G(JVM需要额外的一些非堆空间),那么页数就是18G / 2MB = 9216。
2、配置系统的大页池以具有所需的页数(需要root权限):
$ echo 9216 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages
3、添加参数-XX:+UseLargePages 启动程序进行测试
总结
垃圾回收器的组合关系虽然很多,但是针对几个特定的版本,比较好的组合选择如下:
JDK8及之前:
ParNew + CMS(关注暂停时间)、Parallel Scavenge + Parallel Old (关注吞吐量)、 G1(JDK8之前不建议,较大堆并且关注暂停时间)
JDK9之后:
G1(默认)
shenandoah gc stw少 大对象影响大
zgc stw少-堆大小无影响-并发低