HashMap线程不安全性

HashMap的底层结构以JDK1.8为一个分界线，JDK1.8之前和JDK1.8及之后的底层结构稍有不同，下面分别以JDK1.7和JDK1.8为例来介绍HashMap的底层实现。

JDK1.7中HashMap

底层结构

HashMap底层是一个数组table，数组中的每一项都是一个Entry，Entry是一个K-V对，我们所存入的键值对全都存放在Entry中。数组table的每个位置我们常称为一个桶，每个桶可能会对应多个Entry，多个Entry以链表的形式连接，此结构我们称为数组+链表结构。如下图所示：

数组中每个位置上可能有0个、1个或多个Entry元素，这个取决于根据hash映射结果算出来的键值对在数组中的下标，若多个键值对下标相同，那么以链表的形式组织。JDK1.7使用的hash映射方法如下所示。

hash映射

计算Entry在数组中的下标时分两步：

1.计算key的哈希值；

	final int hash(Object k) {
        int h = 0;
        h ^= k.hashCode();

        h ^= (h >>> 20) ^ (h >>> 12);
        return h ^ (h >>> 7) ^ (h >>> 4);
    }

2.根据哈希值计算下标。

static int indexFor(int h, int length) {
        return h & (length-1);
    }

计算出下标之后，就可以将待加入的键值对插入数组下标处对应的链表中，JDK1.7中采用的是头插法，每次将新的元素插入到链表头。

线程不安全分析

HashMap不是线程安全的，在并发情况下会导致线程不安全，主要分为两种情况：

1.多线程put操作，元素丢失问题

假设这时有两个线程：线程A和线程B同时向table中put新元素，如图所示，线程A做put(<k4,v4>)操作，线程B做put(<k5,v5>)操作，并且假设这两个键值对映射到table中的下标一样，都为7。

如下图所示，为了表示方便，所以在有数据的链表后都加上了一个null表示上一个元素的next的null。线程A与线程B都拥有自己的e与next，e表示头指针，next表示头指针指向的第一个元素，初始时，e和next都指向null。这里假设线程A开始执行put()方法，首先求得<K4,v4>在数组中的下标，然后获得该下标处的头指针e和next值，但是执行到这一步，线程A停止，不往下执行。目前线程A的状态如下所示。

接下来执行线程B，线程B首先也要获得e和next值，并且线程B会顺利执行完，那么线程B执行完之后table的状态变为下图所示状态，线程B的<k5,v5>插入成功。蓝色的线表示线程A的指针，橘色的线表示线程B的指针。

接下来，线程A继续执行，但是线程A使用的e和next仍然是线程B执行之前获得的值，那么线程A插入元素<k4,v4>之后就会产生如下所示的状态。

可以看出在下标为7处，只连接了线程A插入的元素<k4,v4>，线程B之前插入的元素不在链表中，这就导致了数据的丢失。

2.多线程resize操作，死循环问题（由于头插法导致）

当HashMap中的元素个数达到其规定的阈值后，HashMap需要扩容，在扩容的临界条件下，当两个线程（多个线程也会引起这样的问题，这里用两个线程举例）同时向HashMap中put新元素时，两个线程都会导致HashMap的扩容操作，这时可能就会导致死循环问题，请看下面实例。
初始时假设HashMap容量为4，其中元素如下图所示。

线程A执行

这时有线程A要做put(<k4,v4>)操作，线程B做put(<k5,v5>)操作，假设线程A先执行，首先将元素<k4,v4>插入到对应位置。table状态如下图所示。这时table中元素的数目为4 > (4 * 0.75)，刚好达到扩容的阈值，所以这里会进行扩容，生成一个线程私有的newTable数组，来存储扩容之后的信息。

假设扩容后，<k1,v1>、<k2,v2>对应的下标为2，<k3,v3>对应的下标为4，<k4,v4>对应的下标为6。
下图是开始扩容时两数组的状态，上方是HashMap的table数组，下面是线程A私有的newTable数组，初始时为空，

图表示的是在线程A中将第一个元素<k1,v1>移动到newTable后状态。<k1,v1>连接到newTable[2]之后，接下来移动<k2,v2>。

移动第二个元素<k2,v2>，得到如下所示的状态。

线程A执行到这里先暂停（可能cpu时间片用完，失去cpu），接下来线程B执行。

线程B执行

假设这时线程A停止，线程B开始执行，线程B操作的还是之前的table，首先插入元素<k5,v5>，table的状态变为下图。

这时table需要扩容，线程B同时也生成一个线程B私有的newTable，存储扩容之后的信息。将table中的<k1,v1>移动到newTable中后，可以得到下图所示的状态。（这里要注意，虽然线程B用的还是table中的元素位置，但是实际上链表中元素的连接已经改变了，比如原来table中Entry<k1,v1>的next是Entry<k2,v2>，但是线程A操作完之后，实际上已经变为了Entry<k2,v2>的next是Entry<k1,v1>）。

接下来移动next所指元素<k2,v2>，得到下图所示的状态。

接着再处理next<k1,v1>，得到下图。

再继续处理next<k2,v2>，我们发现会得到一个环，这时就发生了死循环。

导致死循环的是头插法的缺陷，在resize转移元素时，会将原table中的元素倒序，会产生死循环。

JDK1.8中HashMap

底层结构

JDK1.8中HashMap底层也是一个数组table，和JDK1.7中结构基本相同，只是之前的链表结构在一些特殊情况下效率会比较低，比如链表长度比较长时，查询和插入时间（JDK1.8中使用的是尾插法）就会比较长。那么在JDK1.8中，对链表做了改进，当链表长度超过8时，就会转换为红黑树，以此来加快插入和查询时间。此结构我们称为数组+链表/红黑树结构。如下图所示：

数组中每个位置上可能有0个、1个或多个Entry元素，这个取决于根据hash映射结果算出来的键值对在数组中的下标，若多个键值对下标相同，那么以链表的形式组织。JDK1.7使用的hash映射方法如下所示。

hash映射

计算键值对在数组table中的下标时分两步：

1.计算key的哈希值；

	static final int hash(Object key){
		int h;
		return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16);
	}

2.根据哈希值计算下标。

	index = (n - 1) & hash;

计算出下标之后，就可以将待加入的键值对插入数组下标处对应的链表中，JDK1.8中采用的是尾插法，每次将新的元素插入到链表尾或红黑树中。

线程不安全分析

JDK1.8中采用的插入方式是尾插法，这是因为头插法在多线程时可能会导致死循环，使用尾插法可以避免这样的情况发生。
但是针对JDK1.7中第一种线程不安全的情况，使用尾插法时依然存在，并且情况类似，不再赘述。

总结

对比	JDK1.7	JDK1.8
底层结构	数组+链表	数组+红黑树
元素插入方式	头插法	尾插法
线程不安全情况	①多线程put()操作时元素丢失；②多线程resize()时形成死循环。	①多线程put()操作时元素丢失。