HashMap与ConcurrentHashMap的内存占用与get操作性能比较

一、测试背景

        项目中需要提供一个单机计算视频相似度的服务,计算的方式是对视频标题进行分词,提取关键词,然后通过word2vec的方式对关键词进行embedding,最后通过向量累加得到视频的词向量,然后通过某种相似度算法(比如欧式距离)得到视频相似度。这个服务要求5ms返回,可行性预研阶段需要估算响应时间能否达到要求,需要多少台机器支撑每天50亿的请求量。这里面有两个关键内容需要估算,一个是响应时间是多少,能否达到5ms的要求;另一个是每个服务需要多少存储空间(从而估算一台64G的机器能跑几个实例,这里假定一个实例能支撑的QPS是已知的)。这个服务中占用内存最大的是存储80万的词向量,时间消耗比较大的地方也是词向量的读取。

二、实现思路

         每次计算视频相似度需要大概查询150次词向量(50个视频乘以3个关键词),大量的时间都花在词向量查询,如果使用分布式缓存进行存储词向量,都不能够达到预期,所以初步设计是存在内存中,使用HashMap进行存储,Map的key是关键词,value是一个float数组。我们从生成好的80万词向量文件中随机抽取了10%的数据约81000行,样例文件大小225M,数据样例如下:


现在需要对程序使用内存进行预估,来决定申请机器的台数。这块使用了两种方法来预估内存:第一种通过使用java.lang.Runtime.freeMemory()方法来进行粗略的估计,在读取文件到Map前进行调用一次freeMemory方法,然后在数据填充进Map后再调用一次freeMemory,使用第一次的值减去第二次值,就可以得到HashMap近似的内存大小。注意使用这样方法进行预估时,一定要将运行jvm虚拟机-Xms 与-Xmx设置相等。具体代码和运行结果如下:

计算结果HashMap对象占用内存为83M,生成HasMap对象总共占用了约324M内存。

        第二种方法是将生成好的HashMap对象序列化到本地生成文件,查看文件大小近似估计HashMap所占的空间,生成文件大小为95M。

通过上述两种方法测试分析得到,加载10%的数据到HashMap对象时大约需要400M的内存空间,实际保存HashMap需要约100M的内存,依次类推加载所有数据HashMap不超过1.5G,加载HashMap使用内存到的总内存不会超过2G,加上相关性计算及多线程访问需要的内存大约每个实例预估使用4G内存。由于HashMap是线程不安全的,所以每次重新加载数据时需要先临时生成一个HashMap对象将新的数据加载进临时对象中,加载完毕之后将引用对象指向临时生成的HashMap,所以在重新加载对象时使用的内存是实际存储HashMap空间的2倍,也就是一个实例最终需要6G的内存,其中有2G的内存在平时属于空闲状态只有在数据重新加载时才会使用。这样实现很大程度会浪费很多内存空间,增加机器台数,增加了投入成本。实现代码如下:


       因为是HashMap是线程不安全,所以采用了以上实现。如果使用线程安全的ConcurrentHashMap在数据重新加载不需要以上操作节省一个Map存储的内存。使用同样代码对ConcurrentHashMap进行测试,得到ConcurrentHashMap存储所占用的内存约为84M,生成的序列化文件大小为95.3M与HashMap占用内存空间基本一致。现在唯一的问题是确定ConcurrentHashMap读取效率,是否能满足要求,网上查找资料时发现没有比较HashMap和ConcurrentHashMap在多线程下get操作的耗时对比,所以做了以下实验。

三、HashMap与ConcurrentHashMap多线程get操作对比

测试环境

CPU:Intel(R) Xeon(R)CPU E5-2620 0 @ 2.00GHz, 2个物理cpu,每个cpu包含6核心,每个核心4个线程

Jdk1.7版本:jdk1.7.0_80

Jdk1.6版本:jdk1.6.0_45

测试方法

       使用相同的词向量文件分别构造HashMap与ConcurrentHashMap,分别使用1个,12个,24个,48个线程,每个线程循环进行1000000次的get操作达到模拟高并发下的查询,记录测试时间;同样的程序使用jdk1.6与jdk1.7分别进行测试比较耗时。测试代码如下:

测试结果

测试结果如下表所示(每个线程请求1000000次):

 

jdk1.7

jdk1.6

线程数

HashMap

ConcurrentHashMap

HashMap

ConcurrentHashMap

1

42ms

48ms

46ms

62ms

12

52ms

62ms

62ms

76ms

24

70ms

84ms

83ms

96ms

48

137ms

159ms

139ms

174ms


      使用jdk1.7测试结果来看ConcurrentHashMap比HashMap慢20%, HashMap的get操作需要42ns,ConcurrentHashMap的get操作需要48ns。从jdk两个版本对比来看,jdk1.7比jdk1.6大约快20%左右。从测试结果来看,使用ConcurrentHashMap代替HashMap完全没有问题。

结果分析

      ConcurrenHashMap使用了锁分段技术,将Hash表默认分为16个段(桶),每一个段上加一把锁,如果一个段被锁不会影响其他段的线程访问。ConcurrenHashMap 具体是由Segment数组和HashEntry数组构成的。每个Segment都可以理解为是一个HashTable,Segment包含一个HashEntry数组,HashEntry是一个链表结构,每一个Segment守护一个HashEntry数组,要对HashEntry数组操作时必须首先取得Segment的锁,才能更改HashEntry数组中的数据。读取数据是先需要找到数据所在的Segment,然后再在HashEntry数组中找到具体的HashEntry对象,然后从头开始访问链表,找到相同key的返回该对象的值,找不到查next对象的key值是否相同,一直查询到链表结束。从Jdk1.7 ConcurrentHashMap get方法源码可以看出CocurrentHashMap比HashMap进行get操作时,多进行了一次Hash来得到Segment,得到Segment后的操作与HashMap的get方法基本一致,通过一次hash找到HashEntry在数组中的位置,然后从头遍历该链表。CocurrentHashMap在取得Segment和HashEntry时使用了sun.misc.Unsafe类中提供的方法,Unsafe类提供的硬件级别的原子操作,调用操作系统底层提高性能。jdk1.7 CocurrentHashMap与jdk1.6的访问速度差异主要在于,jdk1.6如果在HashEntry中找多对用的key的值,如果值为null会加锁再读一次,而jdk1.7大量使用了Unsafe类提供的方法来提高性能。jdk1.7 CocurrentHashMap与jdk1.6的访问速度差异主要在于,jdk1.6如果在HashEntry中找多对用的key的值,如果值为null会加锁再读一次,而jdk1.7大量使用了Unsafe类提供的方法来提高性能。

参考资料:

http://ifeve.com/sun-misc-unsafe/

http://www.blogjava.net/stevenjohn/archive/2015/03/15/423475.html

http://www.infoq.com/cn/articles/ConcurrentHashMap

http://www.cnblogs.com/ITtangtang/p/3948786.html


©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页