ConcurrentHashMap 性能测试
之前在测试commons-pool2
相关实现的时候,发现在线程接近 500 时候,性能瓶颈降低非常厉害,就好像碰到了总体性能的天花板一样,随着线程继续增加而单线程性能急速下降的现象。当时粗略判断其中一个原因是用来存储对象映射关系的java.util.concurrent.ConcurrentHashMap
存在瓶颈导致。
所以今天我特意来测试一下java.util.concurrent.ConcurrentHashMap
的查询性能,其他增改的功能暂时不做测试了。关于另外一个可能的原因java.util.concurrent.atomic.AtomicLong
,我们下期再测。有兴趣的可以先看看我之前对于更强大的多线程计数器java.util.concurrent.atomic.LongAdder
的性能测试:性能测试中的LongAdder。下面是之前遇到两种不同类型的对象池的性能测试文章:通用池化框架GenericObjectPool性能测试、通用池化框架GenericKeyedObjectPool性能测试。
测试方案
先说一下思路和场景设计。思路还是沿用之前的性能测试,通过固定线程的性能模型进行测试,通过调整次数和线程数来测试java.util.concurrent.ConcurrentHashMap
的性能表现。场景设计上我先把java.util.concurrent.ConcurrentHashMap
添加 N 个key
和value
,然后通过多线程随机从这些key
里面取值。
这样本地测试就有了三个变量线程数
、次数
、key
的数量,本次重点放在了 200 线程以上的性能表现。
PS:硬件和软件配置参考以前的文章,这里就不多说了。
测试用例
照例方案依旧使用FunTester
性能测试框架提供的能力,采取Groovy
脚本实现。相信有一定 Java 基础的同学阅读起来是没有问题的。
测试结果
由于测试中基本都触碰到硬件(CPU)瓶颈,所以本次也就不记录 CPU 使用率了,相当于都是在 CPU 资源有限情况下的性能测试数据,其实测试中发现次数影响也不大。
测试到此,结论比较明显了,影响java.util.concurrent.ConcurrentHashMap
的主要因素还是机器 CPU 资源不够用了。对于相同的资源情况下,线程数更低自然获得更强的单线程性能,如果增加线程确实可以获取更大的总体 QPS。在key
值方面,值越多,QPS 越低。在测试次数上,自然是字数越多,QPS 也大,也符合之前多次测试中的结论。
但是当我重新检查代码的时候却发现一个问题,在com.funtest.groovytest.ConcurrentHashMapTest.FunTester#doing
方法中其实还有一段耗时的请求,就是com.funtester.frame.SourceCode#getRandomInt
,经过我重新测试,发现java.util.concurrent.ConcurrentHashMap
的性能得到了十几倍的提升。
不得不说我大意了,本期文章标题应当修改为java.util.concurrent.ThreadLocalRandom
性能测试。
一下是com.funtester.frame.SourceCode#getRandomInt
的内容:
我依此法重新测试了java.util.concurrent.atomic.AtomicLong
,发现也是 QPS 超高,排除了我之前的想法。看来commons-pool2
的瓶颈不在这两个地方。以后等我仔细再研究研究,有结论再跟大家分享。
Have Fun ~ Tester !
阅读原文,跳转我的仓库地址
版权声明: 本文为 InfoQ 作者【FunTester】的原创文章。
原文链接:【http://xie.infoq.cn/article/a36d2c48223bf468fce28399f】。文章转载请联系作者。
评论