为什么说HashMap是线程不安全的呢？
它在多线程环境下，会发生什么情况呢？
先看HashMap中rezise()方法源码
final Node[] resize() {
Node[] oldTab = table;
int oldCap = (oldTab == null) ? 0 : oldTab.length;
int oldThr = threshold;
int newCap, newThr = 0;
if (oldCap > 0) {
if (oldCap >= MAXIMUM_CAPACITY) {
threshold = Integer.MAX_VALUE;
return oldTab;
}
else if ((newCap = oldCap = DEFAULT_INITIAL_CAPACITY)
newThr = oldThr 0) // initial capacity was placed in threshold
newCap = oldThr;
else {
// 第一次插入值的时候，table=null,所以给数组进行初始化，设置容量，阈值
newCap = DEFAULT_INITIAL_CAPACITY;
newThr = (int)(DEFAULT_LOAD_FACTOR * DEFAULT_INITIAL_CAPACITY);
}
if (newThr == 0) {
float ft = (float)newCap * loadFactor;
newThr = (newCap [] newTab = (Node[])new Node[newCap];
table = newTab;
if (oldTab != null) {
for (int j = 0; j e;
if ((e = oldTab[j]) != null) {
oldTab[j] = null;
if (e.next == null)
newTab[e.hash & (newCap - 1)] = e;
else if (e instanceof TreeNode)
((TreeNode)e).split(this, newTab, j, oldCap);
else { // preserve order
Node loHead = null, loTail = null;
Node hiHead = null, hiTail = null;
Node next;
do {
next = e.next;
//如果异或运算=0，则位置不变
if ((e.hash & oldCap) == 0) {
if (loTail == null)
loHead = e;
else
loTail.next = e;
loTail = e;
}
else {
if (hiTail == null)
hiHead = e;
else
hiTail.next = e;
hiTail = e;
}
} while ((e = next) != null);
if (loTail != null) {
loTail.next = null;
newTab[j] = loHead;
}
if (hiTail != null) {
hiTail.next = null;
//如果这个数据是在table[2]上，并且此时数组的容量是16.
//那么新的位置将变成new_index=2+16
newTab[j + oldCap] = hiHead;
}
}
}
}
}
return newTab;
} HashMap初始容量大小为16,一般来说，当有数据要插入时，都会检查容量有没有超过设定的thredhold=负载因子*16，如果超过，需要增大Hash表的尺寸，但是这样一来，整个Hash表里的元素都需要被重算一遍。这叫rehash，这个成本相当的大。
对索引数组中的元素for循环遍历：
对链表上的每一个节点遍历：用 next 取得要转移那个元素的下一个，将 e 转移到新 Hash 表的头部，使用头插法插入节点。
循环2，直到链表节点全部转移
循环1，直到所有索引数组全部转移
经过这几步，我们会发现转移的时候是逆序的。假如转移前链表顺序是1->2->3，那么转移后就会变成3->2->1。
这时候就有点头绪了，死锁问题不就是因为1->2的同时2->1造成的吗？所以，HashMap 的死锁问题就出在这个for循环遍历
单线程的rezise
- 假设hash算法就是最简单的 key mod table.length（也就是数组的长度）。
- 最上面的是old hash 表，其中的Hash表的 size = 2, 所以 key = 3, 7, 5，在 mod 2以后碰撞发生在 table[1]
- 接下来的三个步骤是 Hash表 resize 到4，并将所有的
重新rehash到新 Hash 表的过程
多线程rezise
- 因为是单向链表，如果要转移头指针，一定要保存下一个结点，不然转移后链表就丢了
- e 要插入到链表的头部，所以要先用 e.next 指向新的 Hash 表第一个元素（为什么不加到新链表最后？因为复杂度是 O（N））
- 现在新 Hash 表的头指针仍然指向 e 没转移前的第一个元素，所以需要将新 Hash 表的头指针指向 e
- 转移 e 的下一个结点
现在的状态：
从上面的图我们可以看到，因为线程1的 e 指向了 key(3)，而 next 指向了 key(7)，在线程2 rehash 后，就指向了线程2 rehash 后的链表。
然后线程1被唤醒了：
- 执行e.next = newTable[i]，于是 key(3)的 next 指向了线程1的新 Hash 表，因为新 Hash 表为空，所以e.next = null，
- 执行newTable[i] = e，所以线程1的新 Hash 表第一个元素指向了线程2新 Hash 表的 key(3)。好了，e 处理完毕。
- 执行e = next，将 e 指向 next，所以新的 e 是 key(7)
然后该执行 key(3)的 next 节点 key(7)了:
- 现在的 e 节点是 key(7)，首先执行Entry
next = e.next,那么 next 就是 key(3)了 - 执行e.next = newTable[i]，于是key(7) 的 next 就成了 key(3)
- 执行newTable[i] = e，那么线程1的新 Hash 表第一个元素变成了 key(7)
- 执行e = next，将 e 指向 next，所以新的 e 是 key(3)
这时候的状态
然后又该执行 key(7)的 next 节点 key(3)了：
- 现在的 e 节点是 key(3)，首先执行Entry
next = e.next,那么 next 就是 null - 执行e.next = newTable[i]，于是key(3) 的 next 就成了 key(7)
- 执行newTable[i] = e，那么线程1的新 Hash 表第一个元素变成了 key(3)
- 执行e = next，将 e 指向 next，所以新的 e 是 key(7)
这时候状态为
很明显，环形链表出现了！！当然，现在还没有事情，因为下一个节点是 null，
所以就遍历完成了，等put()的其余过程搞定后，HashMap 的底层实现就是线程1的新 Hash 表了。
fail-fast
如果在使用迭代器的过程中有其他线程修改了map，那么将抛出ConcurrentModificationException，这就是所谓fail-fast策略。
这个异常意在提醒开发者及早意识到线程安全问题，具体原因请查看ConcurrentModificationException的原因以及解决措施
顺便再记录一个HashMap的问题：
为什么String, Interger这样的wrapper类适合作为键？
String, Interger这样的wrapper类作为HashMap的键是再适合不过了，而且String最为常用。因为String是不可变的，也是final的，而且已经重写了equals()和hashCode()方法了。其他的wrapper类也有这个特点。不可变性是必要的，因为为了要计算hashCode()，就要防止键值改变，如果键值在放入时和获取时返回不同的hashcode的话，那么就不能从HashMap中找到你想要的对象。不可变性还有其他的优点如线程安全。如果你可以仅仅通过将某个field声明成final就能保证hashCode是不变的，那么请这么做吧。因为获取对象的时候要用到quals()和hashCode()方法，那么键对象正确的重写这两个方法是非常重要的。如果两个不相等的对象返回不同的hashcode的话，那么碰撞的几率就会小些，这样就能提高HashMap的性能。
服务器托管，北京服务器托管，服务器租用 http://www.fwqtg.net
机房租用，北京机房租用，IDC机房托管， http://www.e1idc.net
