今天分享的参数是 -XX:ParGCCardsPerStrideChunk
diagnostic(intx, ParGCCardsPerStrideChunk, 256, \
"The number of cards in each chunk of the parallel chunks used during card table scanning")
一个神奇的参数，看描述似乎还是比较迷糊，还是展开来说下。
发生young gc时，有一个特殊的GC Roots，那就是old gen中的对象，当old gen的对象A引用了young gen的对象B，那么对象B是不能被回收的。
所以要在old gen中找出所有和对象A类似的对象（引用了young gen对象），怎么找呢？最暴力的办法就是遍历所有的old gen对象，显然这种方式效率很低下，在HotSpot实现中，提供了一种叫CardTable的数据结构，用来表示一块内存区域，一般是512字节，如果这块内存中有对象引用了young gen对象，那么就标识这个CardTable为Dirty的，这样在内存扫描时，只需要扫描标识为Dirty的内存区域中的对象即可，避免了全old gen的扫描，大大提升了扫描效率。
在ParNew算法中，扫描old gen的CardTable由多个线程完成，其中ParGCCardsPerStrideChunk参数就是每个线程处理的CardTable数量，默认是256个，意思每个线程每次处理大小为 256*512byte = 128K的StrideChunk，如果old gen大小4G，那么一共要处理 4G / 128K = 32K个StrideChunk，这么多的StrideChunk要分配给GC线程，假设有4个线程在并发执行，必然存在任务的调度和分配问题，影响到扫描效率。
如果把这个参数调大，那么每个线程每次处理的StrideChunk也相应变大，总的StrideChunk个数相应的减少，GC线程在不同的StrideChunk切换次数也会减少，这样是不是可以提升一点性能呢？
那么应该调到多大呢？之前看过一篇LinkedIn的Engineering Blog，他们在不同的配置下经过测试之后得出了32768是最佳值的结论，后来很多的人觉得这个值很神奇，不假思索的也设置了这个值，但这个值真的适合你的应用么？这个非常值得怀疑。
之后Twitter的一批人也高了一个OpenJDK的测试，他们发现8192是一个合适的值，公说公有理，婆说婆有理，我们不用太较真，抱着学习的心态就行。
最后，我们看看这个参数的提交者怎么说，一个俄国人Alexey Ragozin，这是他的一篇关于该参数的文章，传送门，他在发现CardTable扫描时的效率问题后，在7u40时patch了这个问题，在他的实验中，对28G和14G分别，且该参数设置成4K，结果如下：
不管怎么说，在他的实验中，GC性能确实提升不少，但也不能说明4K就是一个完美值，该值也只是非常符合他当前的实验而已。
仔细想想，如果old gen中需要扫描的CardTable其实不多，如果盲目的增大该参数，也会得不偿失，这时256未尝不是一个合适的值，需要找到一个平衡点。
因为该参数是diagnostic类型的，所以要使修改的值生效，需要添加下面参数：
-XX:+UnlockDiagnosticVMOptions
-XX:ParGCCardsPerStrideChunk=4096
花了这么长时间来解释这个参数，只是像说明一点，在JVM调优过程中，没有一个参数的值完美的，只有经过不断的调优过程，慢慢的摸索到适合自己应用的最佳参数范围，除非应用对YGC的耗时特别敏感，不到万不得已，不用优化该参数，256也适合大部分情况。但是随着现在机器内存的扩大，适当的增大该参数值（4K），也是没有问题的。
我是占小狼，如果觉得有收获，欢迎关注。
