ConcurrentHashmap实现原理分析

ConcurrentHashmap

ConcurrentHashMap总结
http://www.importnew.com/22007.html

ConcurrentHashMap实现原理及源码分析
http://www.cnblogs.com/chengxiao/p/6842045.html

http://www.cnblogs.com/chengxiao/p/6059914.html#t3
为何HashMap的数组长度一定是2的次幂？

重写equals方法需同时重写hashCode方法
object对象中的 public boolean equals(Object obj)，对于任何非空引用值 x 和 y，当且仅当 x 和 y 引用同一个对象时，此方法才返回 true；
注意：当此方法被重写时，通常有必要重写 hashCode 方法，以维护 hashCode 方法的常规协定，该协定声明相等对象必须具有相等的哈希码。
如下：
(1)当obj1.equals(obj2)为true时，obj1.hashCode() == obj2.hashCode()必须为true
(2)当obj1.hashCode() == obj2.hashCode()为false时，obj1.equals(obj2)必须为false

如果不重写equals，那么比较的将是对象的引用是否指向同一块内存地址，重写之后目的是为了比较两个对象的value值是否相等。特别指出利用equals比较八大包装对象（如int，float等）和String类（因为该类已重写了equals和hashcode方法）对象时，默认比较的是值，在比较其它自定义对象时都是比较的引用地址

hashcode是用于散列数据的快速存取，如利用HashSet/HashMap/Hashtable类来存储数据时，都是根据存储对象的hashcode值来进行判断是否相同的。

这样如果我们对一个对象重写了euqals，意思是只要对象的成员变量值都相等那么euqals就等于true，但不重写hashcode，那么我们再new一个新的对象，当原对象.equals（新对象）等于true时，两者的hashcode却是不一样的，由此将产生了理解的不一致，如在存储散列集合时（如Set类），将会存储了两个值一样的对象，导致混淆，因此，就也需要重写hashcode()

比如，hashmap中，put一个新的对象，当原对象.equals（新对象）等于true时，两者的hashcode却是不一样的，如果不重写hashcode，put操作会put到两个桶，get操作会歧义

原理分析

HashMap是非synchronized，线程不安全，
而Hashtable是线程安全的,对table加锁;
conCurrentHashmap:对桶加锁，保证线程安全的。

JDK6,7中的ConcurrentHashmap主要使用Segment来实现减小锁粒度，把HashMap分割成若干个Segment，在put的时候需要锁住Segment，get时候不加锁，使用volatile来保证可见性，当要统计全局时（比如size），首先会尝试多次计算modcount来确定，这几次尝试中，是否有其他线程进行了修改操作，如果没有，则直接返回size。如果有，则需要依次锁住所有的Segment来计算。

jdk7中ConcurrentHashmap中，当长度过长碰撞会很频繁，链表的增改删查操作都会消耗很长的时间，影响性能,

所以 JDK8 中完全重写了concurrentHashmap,代码量从原来的1000多行变成了 6000多 行，实现上也和原来的分段式存储有很大的区别。

主要设计上的变化有以下几点:
1 、不采用segment而采用node，锁住node来实现减小锁粒度。(桶锁？)
2 、设计了MOVED状态 当resize的中过程中 线程2还在put数据，线程2会帮助resize。
3 、使用3个CAS操作来确保node的一些操作的原子性，这种方式代替了锁。
4、 sizeCtl的不同值来代表不同含义，起到了控制的作用。

至于为什么JDK8中使用synchronized而不是ReentrantLock，我猜是因为JDK8中对synchronized有了足够的优化吧。