hashmap 问题

HashMap为什么是线程不安全的

我们知道hashmap的扩容因子是0.75如果hashmap的数组长度已经使用了75%就会引起扩容，会新申请一个长度为原来两倍的桶数组，然后将原数组的元素重新映射到新的数组中，原有数据的引用会逐个被置为null。就是在resize()扩容的时候会造成线程不安全。另外当一个新节点想要插入hashmap的链表时，在jdk1.8之前的版本是插在头部，在1.8后是插在尾部

那么hashmap什么时候进行扩容呢？当hashmap中的元素个数超过数组大小loadFactor时，就会进行数组扩容，loadFactor的默认值为0.75，也就是说，默认情况下，数组大小为16，那么当hashmap中元素个数超过160.75=12的时候，就把数组的大小扩展为216=32，即扩大一倍，然后重新计算每个元素在数组中的位置，而这是一个非常消耗性能的操作，所以如果我们已经预知hashmap中元素的个数，那么预设数组的大小能够有效的提高hashmap的性能。比如说，我们有1000个元素new HashMap(1000), 但是理论上来讲new HashMap(1024)更合适，不过上面annegu已经说过，即使是1000，hashmap也自动会将其设置为1024。 但是new HashMap(1024)还不是更合适的，因为0.751024 < 1000, 也就是说为了让0.75 * size > 1000, 我们必须这样new HashMap(2048)才最合适，避免了resize的问题。

不安全原因：

(1)在put的时候，因为该方法不是同步的，假如有两个线程A,B它们的put的key的hash值相同，不论是从头插入还是从尾插入，假如A获取了插入位置为x，但是还未插入，此时B也计算出待插入位置为x，则不论AB插入的先后顺序肯定有一个会丢失

(2)在扩容的时候，jdk1.8之前是采用头插法，当两个线程同时检测到hashmap需要扩容，在进行同时扩容的时候有可能会造成链表的循环，主要原因就是，采用头插法，新链表与旧链表的顺序是反的，在1.8后采用尾插法就不会出现这种问题，同时1.8的链表长度如果大于8就会转变成红黑树。

为什么会选择8作为链表转红黑树的阈值。
根据泊松分布，在负载因子默认为0.75的时候，单个hash槽内元素个数为8的概率小于百万分之一，所以将7作为一个分水岭，等于7的时候不转换，大于等于8的时候才进行转换，小于等于6的时候就化为链表。

从线程安全上看 :HashMap,ConcurrentHashMap,Hashtable
Hashtable是线程安全的，它的每个方法中都加入了Synchronize方法。在多线程并发的环境下，可以直接使用Hashtable，不需要自己为它的方法实现同步.
HashMap不是线程安全的，在多线程并发的环境下，可能会产生死锁等问题。使用HashMap时就必须要自己增加同步处理.HashMap进行同步： Map m = Collections.synchronizeMap(hashMap);
虽然HashMap不是线程安全的，但是它的效率会比Hashtable要好很多。这样设计是合理的。在我们的日常使用当中，大部分时间是单线程操作的。HashMap把这部分操作解放出来了。当需要多线程操作的时候可以使用线程安全的ConcurrentHashMap。ConcurrentHashMap虽然也是线程安全的，但是它的效率比Hashtable要高好多倍。因为ConcurrentHashMap使用了分段锁，并不对整个数据进行锁定。

从使用角度上看 :HashMap,ConcurrentHashMap,Hashtable
如果不需要线程安全，那么使用HashMap，如果需要线程安全，那么使用ConcurrentHashMap。HashTable已经被淘汰了，不要在新的代码中再使用它。
每一版本的JDK，都会对HashMap和HashTable的内部实现做优化，比如JDK 1.8的红黑树优化。所以尽可能的使用新版本的JDK，会有性能上有提升。
为什么HashTable已经淘汰了，还要优化它？因为有老的代码还在使用它，所以优化了它之后，这些老的代码也能获得性能提升。