Java线程安全主要体现在3个方面：可见性、原子性、有序性。下文主要从原子性和可见性分析JDK 1.8 中HashMap的线程安全性及ConcurrentHashMap如何实现线程安全。
HashMap中存在的线程安全问题：
1.HashMap在读取Hash槽首元素的时候读取的是工作内存中引用所指向的对象，并发情况下，其他线程修改的值并不能被及时读取到。
2.HashMap在插入新元素的时候，主要会进行两次判断：
2.1 第一次是根据键的hash判断当前hash槽是否被占用，如果没有就放入当前插入对象。并发情况下，如果A线程判断该槽未被占用，在执行写入操作时时间片耗尽。此时线程B也执行获取hash（恰巧和A线程的对象发生hash碰撞）判断该槽未被占用，继而直接插入该对象。然后A线程被CPU重新调度继续执行写入操作，就会将线程B的数据覆盖。（注：此处也有可见性问题）
2.2 第二次是同一个hash槽内，因为HashMap特性是保持key值唯一，所以会判断当前欲插入key是否存在，存在就会覆盖。与上文类似，并发情况下，如果线程A判断最后一个节点仍未发现重复key那么会把以当前对象构建节点挂在链表或者红黑树上，如果线程B在A判断操作和写操作之间，进行了判断和写操作，也会发生数据覆盖。
除此之外扩容也会发生类似的并发问题。还有size的问题，感觉其实高并发情况下这个size的准确性可以让步性能。
ConcurrentHashMap实现线程安全
其实观察后发现HashMap的线程安全主要体现在可见性和TestAndSet操作的非原子性上。解决这两个问题的暴力方法就是给每个方法加锁，synchronized关键字的虚拟机实现保证了原子性和可见性（具体可参考《深入理解Java虚拟机》），HashTable就是这种实现方案。
但这种加锁方式对性能损耗严重，因为锁的是整个this对象，所以读写操作都是线程阻塞的。
ConcurrentHashMap采用一种性能更好的方案，volatile关键字保证可见性，1问题得以解决。
针对2.1问题采用无锁化同步机制，即CAS(需配合volatile)，如果设置成功，跳出循环返回，如果失败继续下次循环重新判断。
针对2.2问题采用synchronized加锁，因为hash槽维度已保证线程安全，故而此处只需保证槽内数据线程安全即可，所以此处加锁的对象是链表首节点或者红黑树。这样就保证了线程安全性。扩容的时候类似。
其实主要就是采用无锁化的手段减少锁的开销，只有发生哈希碰撞才会产生锁竞争，极端情况下，如hash离散性极好，甚至不会发生锁竞争。
此处只是描述了实现思路，具体实现可参考JDK源码。
扩展
ConcurrentHashMap实现确实性能比HashTable要好，但是不利于扩展，例如要增加一个putIfAbsent方法，因为HashTable是锁的HashTable对象，我们可以拿到对象对其进行加锁，然后在加锁代码块内进行判断和添加操作，实现putIfAbsent的原子操作。但我们却无法拿到ConcurrentHashMap的加锁对象，也就没办法进行这种原子操作的扩展。好消息是ConcurrentHashMap已经提供了类似putIfAbsent的常用原子方法，基本能满足需求。此处只是一个引申讨论。
以上是本人的一些浅薄理解，如有错误，请不吝指正。
参考
《深入理解Java虚拟机》
《Java Concurrency in Practice》
