初识ConcurrentHashMap

前言

今天看了一下ConcurrentHashMap的相关资料，在这里做一个总结。

正文

对于HashMap来说，最重要的两个方法就是get()和put()。一种最自然的想法就是对整个HashMap加锁,必然可以得到一个线程安全的对象。但是这样做，我们就认为加锁粒度太大。对于ConcurrentHashMap，它内部进一步细分了若干个小的HashMap，称之为段（SEGMENT）。默认情况下，一个ConcurrentHashMap被进一步细分为16个段。

如果需要在ConcurrentHashMap中增加一个新的表项，并不是将整个HashMap加锁，而是首先根据hashcode得到该表项应该被存放到那个段中，然后对该段加锁，并完成put()操作。在多线程环境中，如果多个线程同时进行put()操作，只要被加入人的表项不存在同一个段中，则线程间便可以做到真正的并行。

由于默认有16个段，因此，如果够幸运的话，ConcurrentHashMap可以同时接受16个线程同时插入（如果都插入在不同段中），从而大大提高其吞吐量。

虽然其put()方法很好地分离了锁，但是当试图访问ConcurrentHashMap的size()方法时，它将返回ConcurrentHashMap的所有效表项的数量，代码码如下：

sum = 0;
for(int i = 0; i < segments.lengthl;++i)
	//对所有的段加锁
	segments[i].lock();
for(int i = 0; i < segments.lengthl;++i)
	//统计总数
	sum += segments[i].count;
for(int i = 0; i < segments.lengthl;++i)
	//释放所有锁
	segments[i].unlock();

可以看到在计算总数时，先要计算所有段的索，然后再求和，但是，ConcurrentHashMap的size()方法并不是总这样执行，事实上size()方法先会使用无锁的方式求和，如果失败才会尝试这种加锁的方法，但不管怎么说，在高并发场合ConcurrentHashMap的size()的性能依然要低于同步的HashMap。

总结

与常规同步的HashMap对比时，只有在类似size()获取全局信息的方法调用并不频繁时，这种减小锁粒度的方法才能真正意义上提高系统吞吐量。