HashMap与ConcurrentHashMap、HashTable

（1）HashMap的线程不安全缘由一：死循环

缘由在于HashMap在多线程状况下，执行resize()进行扩容时容易形成死循环。 
扩容思路为它要建立一个大小为原来两倍的数组，保证新的容量仍为2的N次方，从而保证上述寻址方式仍然适用。扩容后将原来的数组重新插入到新的数组中。这个过程称为reHash。

【单线程下的reHash】 

• 扩容前：咱们的HashMap初始容量为2，加载因子为1，须要向其中存入3个key，分别为五、九、11，放入第三个元素11的时候就涉及到了扩容。
• 第一步：先建立一个二倍大小的数组，接下来把原来数组中的元素reHash到新的数组中，5插入新的数组，没有问题。
• 第二步：将9插入到新的数组中，通过Hash计算，插入到5的后面。
• 第三步：将11通过Hash插入到index为3的数组节点中。

单线程reHash彻底没有问题。

【多线程下的reHash】 

多线程HashMap的resize

咱们假设有两个线程同时须要执行resize操做，咱们原来的桶数量为2，记录数为3，须要resize桶到4，原来的记录分别为：[3,A],[7,B],[5,C]，在原来的map里面，咱们发现这三个entry都落到了第二个桶里面。
假设线程thread1执行到了transfer方法的Entry next = e.next这一句，而后时间片用完了，此时的e = [3,A], next = [7,B]。线程thread2被调度执行而且顺利完成了resize操做，须要注意的是，此时的[7,B]的next为[3,A]。此时线程thread1从新被调度运行，此时的thread1持有的引用是已经被thread2 resize以后的结果。线程thread1首先将[3,A]迁移到新的数组上，而后再处理[7,B]，而[7,B]被连接到了[3,A]的后面，处理完[7,B]以后，就须要处理[7,B]的next了啊，而经过thread2的resize以后，[7,B]的next变为了[3,A]，此时，[3,A]和[7,B]造成了环形链表，在get的时候，若是get的key的桶索引和[3,A]和[7,B]同样，那么就会陷入死循环。

（2）HashMap的线程不安全缘由二：fail-fast

Fail-safe和iterator迭代器相关。若是某个集合对象建立了Iterator或者ListIterator，而后其它的线程试图“结构上”更改集合对象，将会抛出ConcurrentModificationException异常。但其它线程能够经过set()方法更改集合对象是容许的，由于这并无从“结构上”更改集合。可是假如已经从结构上进行了更改，再调用set()方法，将会抛出IllegalArgumentException异常。结构上的更改指的是删除或者插入一个元素，这样会影响到map的结构。

解决办法：可使用Collections的synchronizedMap方法构造一个同步的map，或者直接使用线程安全的ConcurrentHashMap来保证不会出现fail-fast策略。

Java7 HashMap

不支持并发操做

Java中的数据存储方式有两种结构，一种是数组，另外一种就是链表，前者的特色是连续空间，寻址迅速，可是在增删元素的时候会有较大幅度的移动，因此数组的特色是查询速度快，增删较慢。

而链表因为空间不连续，寻址困难，增删元素只需修改指针，因此链表的特色是查询速度慢、增删快。

那么有没有一种数据结构来综合一下数组和链表以便发挥他们各自的优点？答案就是哈希表。

 

HashMap 里面是一个数组，而后数组中每一个元素是一个单向链表。

上图中，每一个绿色的实体是嵌套类 Entry 的实例，Entry 包含四个属性：key, value, hash 值和用于单向链表的 next。

capacity：当前数组容量，始终保持 2^n，能够扩容，扩容后数组大小为当前的 2 倍。

HashMap的长度为何要是2的n次方

loadFactor：负载因子，默认为 0.75。

threshold：扩容的阈值，等于 capacity * loadFactor

put 过程分析

数组初始化

在第一个元素插入 HashMap 的时候作一次数组的初始化，就是先肯定初始的数组大小，并计算数组扩容的阈值。

1. 求 key 的 hash 值

     int  hash = hash(key);

2. 找到对应的数组下标

     int  i = indexFor(hash, table.length);

3.放入链表头部

数组扩容

在插入新值的时候，若是当前的 size 已经达到了阈值，而且要插入的数组位置上已经有元素，那么就会触发扩容，扩容后，数组大小为原来的 2 倍。

get 过程分析

1.根据 key 计算 hash 值。

2.找到相应的数组下标：hash & (length – 1)。

3.遍历该数组位置处的链表，直到找到相等(==或equals)的 key。

Java7 ConcurrentHashMap

——基于分段锁的ConcurrentHashMap

• Java7里面的ConcurrentHashMap的底层结构仍然是数组和链表，与HashMap不一样的是ConcurrentHashMap的最外层不是一个大的数组，而是一个Segment数组。每一个Segment包含一个与HashMap结构差很少的链表数组。
• 当咱们读取某个Key的时候它先取出key的Hash值，并将Hash值的高sshift位与Segment的个数取模，决定key属于哪一个Segment。接着像HashMap同样操做Segment。
• 为了保证不一样的Hash值保存到不一样的Segment中，ConcurrentHashMap对Hash值也作了专门的优化。

• Segment继承自J.U.C里的ReetrantLock，因此能够很方便的对Segment进行上锁。即分段锁。理论上最大并发数是和segment的个数是想等的。 

初始化

initialCapacity：初始容量，这个值指的是整个 ConcurrentHashMap 的初始容量，实际操做的时候须要平均分给每一个 Segment。

loadFactor：负载因子，以前咱们说了，Segment 数组不能够扩容，因此这个负载因子是给每一个 Segment 内部使用的。扩容是 segment 数组某个位置内部的数组 HashEntry<k,v>[] 进行扩容，扩容后，容量为原来的 2 倍。

put 过程分析

1. 计算 key 的 hash 值

2. 根据 hash 值找到 Segment 数组中的位置 

3.再利用 hash 值，求应该放置的segment 内部的数组下标

4.添加到头部

get 过程分析

1.计算 hash 值，找到 segment 数组中的具体位置，或咱们前面用的“槽”

2.槽中也是一个数组，根据 hash 找到数组中具体的位置 

3.到这里是链表了，顺着链表进行查找便可

Java8 HashMap

Java8 对 HashMap 进行了一些修改，最大的不一样就是利用了红黑树，因此其由 数组+链表+红黑树 组成。

根据 Java7 HashMap 的介绍，咱们知道，查找的时候，根据 hash 值咱们可以快速定位到数组的具体下标，可是以后的话，须要顺着链表一个个比较下去才能找到咱们须要的，时间复杂度取决于链表的长度，为 O(n)。

Java 8为进一步提升并发性，摒弃了分段锁的方案，而是直接使用一个大的数组。同时为了提升哈希碰撞下的寻址性能，Java 8在链表长度超过必定阈值（8）时将链表（寻址时间复杂度为O(N)）转换为红黑树（寻址时间复杂度为O(long(N))）。

java8也是经过计算key的hash值和数组长度值进行取模肯定该key在数组中的索引。可是java8引入红黑树，即便hash冲突比较高，寻址效率也会是比较高的。

来一张图简单示意一下吧：

Java7 中使用 Entry 来表明每一个 HashMap 中的数据节点，Java8 中使用 Node，基本没有区别，都是 key，value，hash 和 next 这四个属性，不过，Node 只能用于链表的状况，红黑树的状况须要使用 TreeNode。

咱们根据数组元素中，第一个节点数据类型是 Node 仍是 TreeNode 来判断该位置下是链表仍是红黑树的。

put 过程分析

参考get过程

get 过程分析

1. 计算 key 的 hash 值，根据 hash 值找到对应数组下标: hash & (length-1)
2. 判断数组该位置处的元素是否恰好就是咱们要找的，若是不是，走第三步
3. 判断该元素类型是不是 TreeNode，若是是，用红黑树的方法取数据，若是不是，走第四步
4. 遍历链表，直到找到相等(==或equals)的 key

Java8 ConcurrentHashMap

——基于CAS的ConcurrentHashMap

比java8的HashMap复杂不少，可是结构差很少全。

同步方式

对于put操做，若是Key对应的数组元素为null，则经过CAS操做将其设置为当前值。若是Key对应的数组元素（也即链表表头或者树的根元素）不为null，则对该元素使用synchronized关键字申请锁，而后进行操做。若是该put操做使得当前链表长度超过必定阈值，则将该链表转换为树，从而提升寻址效率。

对于读操做，因为数组被volatile关键字修饰，所以不用担忧数组的可见性问题。同时每一个元素是一个Node实例（Java 7中每一个元素是一个HashEntry），它的Key值和hash值都由final修饰，不可变动，无须关心它们被修改后的可见性问题。而其Value及对下一个元素的引用由volatile修饰，可见性也有保障

 

HashMap和ConcurrentHashMap对比：

• HashMap非线程安全、ConcurrentHashMap线程安全
• HashMap容许Key与Value为空，ConcurrentHashMap不容许
• HashMap不容许经过迭代器遍历的同时修改，ConcurrentHashMap容许。而且更新可见

 

 HashMap和HashTable的对比：

（1）HashMap是非线程安全的，HashTable是线程安全的。

（2）HashMap的键和值都容许有null存在，而HashTable则都不行。

（3）由于线程安全、哈希效率的问题，HashMap效率比HashTable的要高。

 

HashTable和ConcurrentHashMap对比：

HashTable里使用的是synchronized关键字，这实际上是对对象加锁，锁住的都是对象总体，当Hashtable的大小增长到必定的时候，性能会急剧降低，由于迭代时须要被锁定很长的时间。ConcurrentHashMap相对于HashTable的syn关键字锁的粒度更精细了一些，并发性能更好。

 问题：在put的时候是放在链表头部仍是尾部？

jdk1.7以前是放在链表头部在jdk1.8以后是放在尾部。