Java 提供了不同层面的线程安全支持。在传统集合框架内部，除了 Hashtable 等同步容器，还提供了所谓的同步包装器（Synchronized Wrapper），我们可以调用 Collections 工具类提供的包装方法，来获取一个同步的包装容器（如 Collections.synchronizedMap），

但是它们都是利用非常粗粒度的同步方式，在高并***况下，性能比较低下。

更加普遍的选择是利用并发包提供的线程安全容器类，
它提供了：

各种并发容器，比如 ConcurrentHashMap、CopyOnWriteArrayList。
各种线程安全队列（Queue/Deque），如 ArrayBlockingQueue、SynchronousQueue。
各种有序容器的线程安全版本等。

具体保证线程安全的方式，包括有从简单的 synchronize 方式，到基于更加精细化的，比如基于分离锁实现的 ConcurrentHashMap 等并发实现等。具体选择要看开发的场景需求，总体来说，并发包内提供的容器通用场景，远优于早期的简单同步实现。

Hashtable 本身比较低效，因为它的实现基本就是将 put、get、size 等各种方法加
上“synchronized”。简单来说，这就导致了所有并发操作都要竞争同一把锁，一个线程在进
行同步操作时，其他线程只能等待，大大降低了并发操作的效率。

早期 ConcurrentHashMap，其实现是基于：

分离锁，也就是将内部进行分段（Segment），里面则是 HashEntry 的数组，和 HashMap
类似，哈希相同的条目也是以链表形式存放。

HashEntry 内部使用 volatile 的 value 字段来保证可见性，也利用了不可变对象的机制以改
进利用 Unsafe 提供的底层能力，比如 volatile access，去直接完成部分操作，以最优化性
能，毕竟 Unsafe 中的很多操作都是 JVM intrinsic 优化过的。

在构造的时候，Segment 的数量由所谓的 concurrentcyLevel 决定，默认是 16，也可以在相应构造函数直接指定。注意，Java 需要它是 2 的幂数值，如果输入是类似 15 这种非幂*值，会被自动调整到 16 之类 2 的幂数值。

在 Java 8 和之后的版本中，ConcurrentHashMap 发生了哪些变化呢？

总体结构上，，同样是大的桶（bucket）数组，然后内部也是一个个所谓的链表结构（bin），同步的粒度要更细致一些。其内部仍然有 Segment 定义，但仅仅是为了保证序列化时的兼容性而已，不再有任何结构上的用处。
因为不再使用 Segment，初始化操作大大简化，修改为 lazy-load 形式，这样可以有效避免
初始开销。
数据存储利用 volatile 来保证可见性。
使用 CAS 等操作，在特定场景进行无锁并发操作。
使用 Unsafe、LongAdder 之类底层手段，进行极端情况的优化。