一、线程不安全的原因
jdk1.7和jdk1.8中HashMap都是线程不安全的，那就具体讲一下为什么会线程不安全(两个方面)。
（1）调用put方法
假如有两个线程A和B，A希望插入一个key-value到HashMap中，首先会通过A的key得到桶的索引坐标，然后获取该桶的链表头结点，线程A的时间片用完，而此时B线程被调用执行，和线程A一样执行，只不过线程B成功的将数据插入到桶里面。假设线程A插入时候计算的坐标和B线程要插入的索引坐标是一致的，那么当B线程成功插入以后，线程A再次被调用运行的时候，它依然持有原来的链表头，但是它对B线程插入的过程一无所知，那么线程A就会对此坐标上的数据进行覆盖，那么线程B插入的数据就会消失，造成数据不一致的行为。
（2）扩容
JDK7版本中的HashMap扩容时使用头插法，假设此时有元素一指向元素二的链表，当有两个线程使用HashMap扩容的时，若线程一在迁移元素时阻塞，但是已经将指针指向了对应的元素，线程二正常扩容，因为使用的是头插法，迁移元素后将元素二指向元素一。此时若线程一被唤醒，在现有基础上再次使用头插法，将元素一指向元素二，形成循环链表。若查询到此循环链表时，便形成了死锁。而JDK8版本中的HashMap在扩容时保证元素的顺序不发生改变，就不再形成死锁，但是注意此时HashMap还是线程不安全的。
二：如何解决HashMap线程安全问题？
解决线程安全问题的方式有多种比如：
- 比如使用
HashTable - 使用
Collection.synchronizedMap - 使用
ConcurrentHashMap
在使用HashTable或者Collection.synchronizedMap中，这两者有着共同的问题：那就是性能问题。
无论读操作还是写操作，它们都会给整个集合进行加锁，导致同一时间内其他的操作进入阻塞状态。
那么在并发环境下，能够兼顾线程安全和运行效率的情况下就要使用concurrentHashMap
concurrentHashMap在JDK1.7和1.8的版本改动比较大
JD1.7底层是使用数组+链表来实现的，使用分段锁来保证线程安全的，将数组分层了16段，给每个Segment分配一把锁，在读每一个Segment的时候先获取对应的锁，所以最多16个线程并发进行操作。
而JDK1.8和HashMap一样加入了红黑树，使用Node数组+链表+红黑树结构，避免链表过长导致性能的问题，抛弃了Segment和分段锁，改为使用CAS+synchronized关键字实现一种更加细粒度的锁，将锁的级别控制在了更细粒度的哈希桶数组元素级别，也就是说只需要锁住这个链表头节点（红黑树的根节点），就不会影响其他的哈希桶数组元素的读写，大大提高了并发度。
当数组长度到达64且链表长度大于8时，链表转为红黑树。
JDK1.8 中为什么使用内置锁 synchronized替换 可重入锁 ReentrantLock？
- 在 JDK1.6 中，对 synchronized 锁的实现引入了大量的优化，并且 synchronized 有多种锁状态，会从无锁 ->偏向锁 -> 轻量级锁 -> 重量级锁一步步转换。
- 减少内存开销 。假设使用可重入锁来获得同步支持，那么每个节点都需要通过继承 AQS来获得同步支持。但并不是每个节点都需要获得同步支持的，只有链表的头节点（红黑树的根节点）需要同步，这无疑带来了巨大内存浪费。
