JVM调优:CardTable简介

内容简介：JVM调优:CardTable简介

网上关于JVM调优的文章很多,这篇文章主要介绍JVM里Card Table的作用。我们知道JVM GC可以分为MinorGC、MajorGC和FullGC,对于Mirnor GC来讲它的耗时主要由两个因素决定:

1. 复制活跃对象的时间
2. 扫描card table(老年代对象引用新生代对象)的时间

Java虚拟机用了一个叫做CardTable(卡表)的数据结构来标记老年代的某一块内存区域中的对象是否持有新生代对象的引用,卡表的数量取决于老年代的大小和每张卡对应的内存大小，每张卡在卡表中对应一个比特位,当老年代中的某个对象持有了新生代对象的引用时,JVM就把这个对象对应的Card所在的位置标记为dirty(bit位设置为1)，这样在Minor GC时就不用扫描整个老年代，而是扫描Card为Dirty对应的那些内存区域。

这样子可以提高效率减少MinorGC的停顿时间。

在JVM中,一个Card的大小是512字节,在多个线程并行收集时,JVM通过ParGCCardsPerStrideChunk参数设置每个线程每次扫描的Card数量，默认是256，相当于是把老年代分成许多strides，每个线程每次扫描一个stride，每个stride大小为512*256 = 128K，如果你的老年代大小为4G,那总共有4G/128K=32K个Strides。多线程在扫描这么多的strides时就涉及到调度和分配的问题,stride数量太多就会导致线程在stride之间切换的开销增加，进而导致GC暂停时间增长。因此JVM提供了ParGCCardsPerStrideChunk这个参数来配置每个stride对应的card数量，这个数量要根据实际的业务场景进行调优,网上一般流传3个魔术数字:32768、4K和8K。

-XX:+UnlockDiagnosticVMOptions
-XX:ParGCCardsPerStrideChunk=4096

这个值不能设置的太大，因为GC线程需要扫描这个stride中老年代对象持有的新生代对象的引用，如果只有少量引用新生代的对象那就导致浪费了很多时间在根本不需要扫描的对象上。

参考文档:

1. Secret HotSpot option improving GC pauses on large heaps
2. Advanced JVM and GC tuning

以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持 码农网

关注我们，获取更多IT资讯^_^

查看所有标签

• Transformers 简介（上）
• Python 简介
• Istio简介
• RabbitMQ简介和使用
• Python简介
• 001.Kubernetes简介

本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。