1.HashMap的问题
它根据键的hashCode值存储数据，大多数情况下可以直接定位到它的值，因而具有很快的访问速度，但遍历顺序却是不确定的。HashMap最多只允许一条记录的键为null，允许多条记录的值为null。HashMap非线程安全，即任一时刻可以有多个线程同时写HashMap，可能会导致数据的不一致。如果需要满足线程安全，可以用 Collections的synchronizedMap方法使HashMap具有线程安全的能力，或者使用ConcurrentHashMap。
在jdk8的HashMap中，假如A线程和B线程都在做put操作，当线程A通过hash函数计算出插入位置是table[i]，它就获取了头节点，但是还没来得及写入时间片就耗尽，轮到到线程B执行了，线程B通过hash函数计算得出插入位置也是table[i]，它就获取头节点然后插入了，再轮到线程A执行的时候，它直接就在头节点处插入了。造成线程A的写操作覆盖了线程B的写操作。
总结：在获取头结点和插入Entry之间发生了线程切换
2.Hashtable的使用注意事项
Hashtable是遗留类，很多映射的常用功能与HashMap类似，不同的是它承自Dictionary类，并且是线程安全的，任一时间只有一个线程能写Hashtable，并发性不如ConcurrentHashMap，因为ConcurrentHashMap引入了分段锁。Hashtable不建议在新代码中使用，不需要线程安全的场合可以用HashMap替换，需要线程安全的场合可以用ConcurrentHashMap替换。
HashTable 只有一把锁，当一个线程访问HashTable的同步方法时，会将整张table 锁住，当其他线程也想访问HashTable 同步方法时，就会进入阻塞或轮询状态。也就是确保同一时间只有一个线程对同步方法的占用，避免多个线程同时对数据的修改，确保线程的安全性。
但HashTable 对get，put，remove 方法都使用了同步操作，这就造成如果两个线程都只想使用get 方法去读取数据时，因为一个线程先到进行了锁操作，另一个线程就不得不等待，这样必然导致效率低下，而且竞争越激烈，效率越低下。
3.ConcurrentHashMap
在HashMap 的基础上，ConcurrentHashMap 将数据分为多个segment（默认16个），然后然后每次操作对一个segment 加锁，Hashtable 在竞争激烈的并发环境下表现出效率低下的原因是，由于所有访问Hashtable的线程都必须竞争同一把锁，而ConcurrentHashMap 将数据分到多个segment 中（默认16，也可在申明时自己设置，不过一旦设定就不能更改，扩容都是扩充各个segment 的容量），每个segment 都有一个自己的锁，只要多个线程访问的不是同一个segment 就没有锁争用，就没有堵塞，也就是允许16个线程并发的更新而尽量没有锁争用。
ConcurrentHashMap 的segment 就类似一个Hashtable，但比Hashtable 更加优化，前面说过Hashtable对get，put，remove 方法都会使用锁，而ConcurrnetHashMap 中get 方法是不涉及到锁的
