Java 1.6 之前，synchronized 等价于重量级锁，是通过 Monitor 机制实现的，对应 HotSpot 中的 ObjectMonitor 类，该类基于操作系统提供的 互斥量 实现，而互斥量会引发线程在 内核态 和 用户态 之间的切换，导致重量级锁效率较低。

Java 1.6 之前，synchronized 等价于重量级锁，为提升 synchronized 的性能，1.6 新增了偏向锁、轻量级锁，因此目前 synchronized 对应 3 种锁：

关于重量级锁的实现原理，前面有 3 篇相关文章：

• synchronized 原理（一）：重量级锁：从 Javac 编译器、字节码和 JVM 执行引擎等方面介绍了重量级锁的实现原理；
• JVM 管程介绍：介绍了重量级锁底层依赖的 Monitor 机制；
• 对象的内存布局：介绍对象头中 Mark Word 部分的内容；

本文介绍重量级锁如何与 Monitor 关联起来。

synchronized 加锁、解锁是通过 monitorenter、monitorexit 这两条字节码指令实现的，这两个字节码需要指定一个 对象引用 作为参数，它们底层基于 Monitor 实现加锁、解锁语义。

synchronized 的锁分为重量级锁、轻量级锁、偏向锁 3 种，本文介绍重量级锁的实现原理。

synchronized 作为 Java 内置锁的默认实现，有两种用法：

• 同步方法（实例方法 + static 方法）
• 同步代码块

无论哪种用法，synchronized 的使用效果都一样，即同一时刻，只允许一个线程执行同步方法（or 同步代码块），有多个线程竞争时，其他线程 阻塞 等待。

Java 线程的生命周期 中说过，只有 synchronized 能让线程进入 BLOCKED 状态。

ThreadLocal 本身 并非存储数据的容器，真正的数据 保存在每个线程的 Thread.threadLocals 哈希表中，ThreadLocal 作用有两点：

• ThreadLocal 类定义了操作 threadLocals 的各种操作，是存取 threadLocals 的入口；
• ThreadLocal 实例作为 threadLocals 中映射的 键；

本文主要关注第二点 ThreadLocal 实例对象用作 key 的细节。

既然 ThreadLocal 用以实现线程本地变量，那线程终止时，需要删除这些过期数据，否则会发生内存泄漏。

ThreadLocalMap 以 Entry 为元素，ThreadLocal 实例亲自做哈希表中的 key：

1
2
3
4

static class Entry extends WeakReference<ThreadLocal<?>> {
    Object value;
    Entry(ThreadLocal<?> k, Object v) { super(k); value = v; }
}

任何哈希表都存在哈希碰撞的问题，有两种解决方式：

• 链表法：HashMap 等
• 线性探测法：ThreadLocalMap

以前写过一篇 ThreadLocal 的源码分析（源码分析 | ThreadLocal），那时只是按部就班地阅读源码，有点只见树木，不见森林的局限，这次从更加宏观的角度分析下 ThreadLocal 的实现原理。

Java 线程模型基于底层操作系统的 线程模型 实现，每个 Java 线程都与一个 OS 线程 一一对应。

OS 和 JVM 都有线程生命周期的概念，它由一系列 线程状态 构成，描述了一个线程生老病死的状态变化，但两者的线程状态并非一一对应。