Java多线程编程

从源码看 Java 多线程：Thread 类、锁机制与并发工具的底层实现

Java 多线程技术是构建高性能并发程序的核心，但其底层实现常被抽象的 API 所掩盖。深入 Thread 类的设计逻辑、锁机制的演化过程以及并发工具的实现原理，不仅能帮助开发者写出更健壮的代码，更能理解 Java 如何在操作系统层面协调多线程工作。

一、Thread 类：线程生命周期的 “管理者”

Thread 类是 Java 多线程的基础载体，其源码设计围绕线程的创建、状态转换与资源调度展开，核心逻辑体现在对操作系统线程的封装与控制。

1. 线程状态的底层维护

Java 线程的生命周期包含新建、就绪、运行、阻塞、终止五种状态，这些状态在源码中通过volatile int threadStatus变量维护。状态转换并非单纯的 Java 层逻辑，而是与操作系统内核线程状态深度绑定：

• 当调用start()方法时，Thread 类会通过native方法（如start0()）向操作系统申请创建内核线程，此时线程从 “新建” 进入 “就绪” 状态，等待 CPU 调度；
• 若线程执行wait()、sleep()或获取锁失败，threadStatus会被标记为阻塞状态，同时操作系统会将该线程从运行队列移至等待队列，释放 CPU 资源；
• 当阻塞条件解除（如notify()被调用、睡眠时间结束），线程需重新竞争 CPU 时间片，进入 “就绪” 状态等待调度。

这种状态管理机制确保了 Java 线程与操作系统线程的协同，既屏蔽了不同系统的底层差异，又保留了对线程行为的精准控制。

2. 线程执行的核心逻辑

Thread 类的run()方法是线程执行的入口，但真正触发执行的是start()而非直接调用run()。源码中start()方法会先检查线程状态（若已启动则抛出IllegalThreadStateException），再通过native方法启动内核线程，最终由操作系统回调run()方法。

这种设计的本质是将 Java 线程的逻辑执行与操作系统的线程调度分离：run()方法仅包含业务逻辑，而start()负责与底层交互，确保线程符合操作系统的调度规则。此外，Thread 类通过priority字段设置线程优先级，底层映射到操作系统的线程优先级（如 Linux 的 nice 值），影响 CPU 调度的概率，但无法保证绝对的执行顺序。

二、锁机制：从 synchronized 到 Lock 的底层演化

jrhz.info

Java 的锁机制是保证并发安全的核心，其底层实现经历了从 JVM 内置锁到 API 级锁的演进，平衡了性能与灵活性。

1. synchronized 的 “锁升级” 之路

synchronized关键字的底层实现依赖于对象头的Mark Word和Monitor（监视器）机制：

• 无锁状态：对象刚创建时，Mark Word存储对象哈希码，此时无线程竞争；
• 偏向锁：当第一个线程获取锁时，Mark Word记录线程 ID，避免每次加锁解锁的 CAS 操作（比较并交换），适用于单线程重复获取锁的场景；
• 轻量级锁：若有其他线程竞争，偏向锁升级为轻量级锁，线程通过 CAS 操作尝试获取锁，失败则自旋等待（避免阻塞），适合短时间竞争；
• 重量级锁：当自旋超过阈值或竞争激烈，轻量级锁膨胀为重量级锁，依赖操作系统的互斥量（Mutex）实现，线程会进入内核态阻塞，适合长时间竞争。

这种升级过程由 JVM 自动完成，核心是通过Mark Word的状态变化（如偏向标志、锁标志位）协调不同竞争强度下的锁策略，在保证安全的同时最大化性能。

2. Lock 接口的 AQS 基石

java.util.concurrent.locks包中的Lock接口（如ReentrantLock）基于AQS（AbstractQueuedSynchronizer） 实现，其底层是一个 “状态变量 + 双向等待队列” 的结构：

• 状态变量：通过volatile int state记录锁的持有状态（0 为未锁定，大于 0 为已锁定，支持重入）；
• 等待队列：当线程获取锁失败，会被包装为节点加入双向链表，通过park()/unpark()进行阻塞与唤醒，避免synchronized的内核态切换开销。

AQS 采用模板方法模式，将获取锁（tryAcquire()）、释放锁（tryRelease()）等逻辑留给子类实现，自身负责队列管理与线程调度。例如ReentrantLock的公平锁与非公平锁，仅在tryAcquire()中差异实现 —— 公平锁会检查队列是否有等待线程，非公平锁则直接尝试 CAS 获取锁，体现了灵活性优势。

三、并发工具类：基于底层机制的高级封装

Java 并发工具类（如CountDownLatch、Semaphore、CyclicBarrier）并非从零构建，而是基于 AQS 或synchronized实现，解决特定场景的并发协调问题。

1. CountDownLatch：等待多线程完成的 “计数器”

其底层依赖 AQS 的共享模式：

• 初始化时设置计数器值（state变量）；
• 线程调用countDown()时通过tryReleaseShared()递减state，直至为 0；
• 等待线程调用await()时，若state未归零则加入 AQS 等待队列，当state为 0 时，通过doReleaseShared()唤醒所有等待线程。

这种设计利用 AQS 的共享模式特性，允许多个线程同时被唤醒，适合 “主线程等待子线程全部完成” 的场景（如测试用例中的资源初始化）。

2. Semaphore：控制并发访问的 “许可证”

Semaphore 通过 AQS 的共享模式实现对资源访问的控制：

• 初始化时设置许可证数量（state）；
• 线程调用acquire()获取许可证（state递减），若不足则进入等待队列；
• 线程调用release()释放许可证（state递增），并唤醒队列中的等待线程。

与ReentrantLock不同，Semaphore 的tryAcquire()和tryRelease()不限制线程身份，任何线程都可释放许可证，适合 “限制并发访问数量” 的场景（如连接池控制）。

3. CyclicBarrier：线程同步的 “栅栏”

CyclicBarrier 的底层通过ReentrantLock和Condition实现：

• 内部维护一个计数器和Condition对象；
• 线程到达栅栏时获取锁并递减计数器，若未达阈值则调用Condition.await()进入等待；
• 最后一个线程到达时，唤醒所有等待线程并重置计数器（支持重复使用）。

相比CountDownLatch，其优势在于可重复利用，且能在所有线程到达后执行指定任务（如汇总结果），适合 “多线程分阶段协作” 场景。

四、底层设计的共性与思想

Java 多线程的底层实现虽复杂，但贯穿三大核心思想：

1. 分层抽象：通过native方法隔离操作系统差异（如 Thread 的start0()），上层提供统一 API，既保证跨平台性，又保留底层优化空间；
2. 性能与安全平衡：从synchronized的锁升级到 AQS 的自旋与阻塞策略，均根据竞争强度动态调整，避免 “一刀切” 的性能损耗；
3. 复用与扩展：AQS 作为并发工具的基础框架，通过模板方法模式实现代码复用，同时允许子类定制核心逻辑，体现了 “高内聚低耦合” 的设计原则。

结语：理解底层，驾驭并发

从 Thread 类的状态管理到 AQS 的队列机制，Java 多线程的底层实现始终围绕 “如何高效协调线程行为” 展开。这些机制并非孤立存在：synchronized的锁升级依赖对象头与 Monitor，并发工具类基于 AQS 或锁机制构建，形成从基础到高级的完整体系。

对于开发者而言，无需死记源码细节，但理解底层逻辑能帮助写出更合理的并发代码 —— 例如知道synchronized的锁升级过程，会避免在单线程场景中过度使用ReentrantLock；了解 AQS 的队列机制，能更好地排查await()/signal()的线程唤醒问题。

Java 多线程的魅力，正在于其用优雅的抽象封装了复杂的底层细节，而揭开这层封装，看到的是性能与安全、灵活与易用的精妙平衡