尧图网页设计 
Java 线程安全问题成因与全套解决方案从基础到高阶目录引言一、线程安全问题的本质与成因2.1 抢占式线程调度执行2.2 多线程修改同一共享变量2.3 非原子性操作2.4 内存可见性问题2.5 指令重排序2.6 典型问题代码示例二、基础解决方案synchronized 与 volatile2.1 synchronized 关键字2.2 volatile 关键字2.3 基础方案的局限与不足三、高阶解决方案JUC 包并发工具3.1 Lock 接口与 ReentrantLock 显式锁3.2 原子类Atomic与 CAS 无锁编程3.3 其他重要的 JUC 并发工具四、性能对比测试与深度分析4.1 测试环境与基准方法4.2 不同锁机制的吞吐量对比4.3 场景化性能分析结论五、线程安全方案选型指南与调优建议5.1 技术选型决策树5.2 锁优化实用建议5.3 实际项目最佳实践六、总结参考资料引言在当今互联网高并发、大数据量的业务场景下多线程并发编程已成为提升应用性能的核心手段。然而多线程犹如一把双刃剑在充分利用 CPU 资源、大幅提升程序响应速度的同时也带来了复杂的线程安全问题。这类问题隐蔽性极强、复现成本极高稍不注意就会导致数据错乱、业务逻辑异常甚至引发生产级别故障。Java 语言作为企业级应用的主流选型从基础的synchronized关键字到高阶的java.util.concurrent简称 JUC并发工具包提供了一套完整、覆盖不同场景的线程安全解决方案。但很多开发者尤其是初级工程师往往停留在 “会用 API” 的阶段对底层原理、适用边界和性能差异缺乏认知导致实际场景中出现各种并发 bug。本文将从线程安全问题的底层成因入手循序渐进地从基础语法级解决方案深入剖析到高阶 JUC 并发工具的底层设计与实战应用。通过大量可直接运行的代码示例、精准的性能对比数据和场景化的选型建议帮助不同阶段的开发者建立完整的并发编程知识体系在实际业务中精准规避线程安全陷阱。一、线程安全问题的本质与成因线程安全问题的本质是多线程环境下对共享资源的无序访问与操作冲突。其核心矛盾在于多线程需要共享资源完成业务协作但 CPU 的并行执行机制又会导致资源操作的顺序被打乱破坏数据的完整性与一致性(3)。要写出高可靠的并发代码必须先理解线程安全问题的五大核心成因以及它们是如何具体引发数据异常的。2.1 抢占式线程调度执行Java 线程的调度模式是抢占式执行—— 操作系统会依据线程优先级、CPU 时间片剩余情况等复杂逻辑随机调度线程执行没有任何固定的全局顺序。这意味着在一个多线程程序中各线程的执行起始时间、执行持续时长、以及线程切换的具体时机都是完全不可控的。这种随机性是所有线程安全问题的根源如果线程能完全按照预设的有序顺序执行或者采用单线程模式根本不会存在并发冲突也就不会有线程安全问题(17)。2.2 多线程修改同一共享变量线程安全问题的另一前提条件是多个线程同时对同一个共享变量执行修改操作。这里的 “共享变量”涵盖了成员变量、静态变量、堆内存中的对象资源等这些资源可以被多个线程同时访问。如果多个线程仅对共享变量执行读取操作或者各线程操作的是不同的变量副本不会引发任何数据冲突但当一个变量同时被多个线程读写时就极有可能产生并发冲突导致最终数据出现偏差(3)。2.3 非原子性操作“原子性” 是指一个操作或多个操作序列不可分割要么全部执行完成要么完全不执行中途不会被任何线程调度打断。在 Java 中很多看似 “独立” 的操作底层实际上是由多条 CPU 指令拼接而成的并不具备原子性。最典型的就是count自增操作这行代码在语法层面是一个整体但在底层 CPU 指令层面实际需要执行三个完整步骤从主内存读取count的当前工作值对读取到的值执行 1 运算将计算后的新值写回主内存如果缺乏同步机制保证多个线程可能在同一时间点交错执行这三个步骤最终导致更新操作丢失数据结果出现偏差(6)。这也是多线程下计数器结果不准的核心原因。2.4 内存可见性问题内存可见性是指一个线程修改了共享变量的值后其他线程能否立即感知到这一变化。导致可见性问题的根源是 Java 内存模型JMM设计的工作内存与主内存的交互机制。为了提升整体执行效率每个线程都拥有独立的工作内存可以理解为 CPU 的各级缓存线程对共享变量的所有读写操作都需要先将主内存中的变量副本读取到工作内存修改后再同步回主内存。如果多个线程各自缓存了共享变量的工作副本一个线程将新值写入主内存后其他线程可能仍然在使用工作内存中的旧副本无法第一时间获取到最新值这就产生了严重的内存可见性问题(1)。在需要及时感知变量状态变化的场景下这类问题会导致业务逻辑异常。2.5 指令重排序为了最大化 CPU 执行效率编译器、JVM 和 CPU 本身都会在保证单线程执行结果不受影响的前提下对实际的指令执行顺序进行重新编排优化。比如程序中写在后面的代码指令可能被调整到前面执行无数据依赖的多条指令可能会被并行执行。这种重排序优化在单线程环境下不会产生任何问题但在多线程环境下线程间没有数据执行依赖重排序就可能会导致程序的实际执行逻辑与预期逻辑产生巨大偏差。比如一个典型的场景线程 A 先执行了变量初始化操作再将标志位设置为 true但由于指令重排序实际执行时线程 A 可能先将标志位设置为 true随后才执行变量初始化操作。此时线程 B 如果看到标志位为 true就会去读取尚未完全初始化的变量直接触发空指针异常或数据错乱这也是指令重排序优化带来的典型线程安全问题(7)。2.6 典型问题代码示例下面通过一个经典的多线程计数器案例复现上述五大成因共同导致的线程安全问题public class ThreadSafetyDemo { #x20; // 共享静态变量 #x20; public static int count 0; #x20; public static void main(String\[] args) throws InterruptedException { #x20; // 定义两个线程分别执行50000次自增操作 #x20; Thread t1 new Thread(() - { #x20; for (int i 0; i 50000; i) { #x20; count; #x20; } #x20; }); #x20; Thread t2 new Thread(() - { #x20; for (int i 0; i 50000; i) { #x20; count; #x20; } #x20; }); #x20; // 启动两个线程 #x20; t1.start(); #x20; t2.start(); #x20; // 主线程等待t1、t2执行完成后再执行后续输出逻辑 #x20; t1.join(); #x20; t2.join(); #x20; // 理论上应该输出100000但实际运行结果几乎都小于预期值 #x20; System.out.println(count的实际最终值 count); #x20; } }代码分析在这个案例中两个线程t1和t2分别对共享变量count执行 50000 次自增操作正常逻辑下程序应该输出 100000。但实际运行时由于以下多重因素的叠加结果几乎永远达不到预期值抢占式执行导致线程切换不可控两个线程同时修改同一个共享变量自增操作count不具备原子性线程间缓存导致内存可见性问题指令重排序进一步加剧了操作序列的混乱。这五种因素的叠加直接导致部分自增操作的执行结果被覆盖更新操作丢失最终的输出结果小于 100000。这是一个非常典型的线程安全问题清晰地展示了缺乏同步控制时多线程程序的共享资源访问会出现严重偏差(19)。二、基础解决方案synchronized 与 volatile针对线程安全的三大核心维度 —— 原子性、可见性、有序性Java 在语言层面提供了两个最基础的同步解决方案synchronized关键字和volatile关键字。二者的组合可以覆盖大多数简单并发场景下的线程安全需求。2.1 synchronized 关键字synchronized是 Java 内置的基于悲观锁思想的同步机制它可以保证同一时间点只有一个线程能进入临界区访问共享资源的代码块确保对共享资源操作的原子性、可见性和有序性是解决线程安全问题最基础的手段(22)。主要用法synchronized有三种不同的使用方式分别对应不同的锁粒度和锁定范围修饰实例方法锁住当前实例对象同一时间只有一个线程能调用该实例的被synchronized修饰的方法。public synchronized void increment() { #x20; count; // 原子性执行不会出现数据错乱 }修饰静态方法锁住当前类的 Class 对象所有该类的实例对象共用同一把锁即使创建多个实例也只有一个线程能执行该静态方法。public static synchronized void staticIncrement() { #x20; count; // 原子性执行不会出现数据错乱 }修饰同步代码块显式指定锁对象锁粒度更灵活可以选择只对需要同步的代码片段加锁避免不必要的性能开销这也是官方推荐的使用方式。public void safeIncrement() { #x20; // 显式指定锁对象通常是共享资源的Class对象或this实例 #x20; synchronized (this) { #x20; count; // 原子性执行不会出现数据错乱 #x20; } }工作原理synchronized的底层是通过对象监视器Monitor机制实现同步的每个 Java 对象在底层都关联一个唯一的 Monitor 锁。当线程尝试获取锁时JVM 会通过 CAS 操作尝试修改对象头的 Mark Word 标记字段如果获取锁成功线程会记录下自己的锁持有状态如果获取失败线程会直接进入同步队列进入阻塞等待状态。在 JDK 6 及以后JVM 对synchronized进行了非常彻底的锁优化引入了包含偏向锁、轻量级锁、重量级锁、自适应自旋、锁消除、锁粗化在内的完整锁升级机制。这些优化极大地降低了加锁和解锁的操作开销让synchronized在低竞争场景下的性能得到了质的提升甚至在部分场景下比显式锁的表现更优秀(30)。2.2 volatile 关键字volatile是 Java 提供的另一个轻量级同步机制它的主要作用是保证变量的内存可见性和禁止指令重排序但不具备原子性保证无法单独解决非原子性操作带来的线程安全问题(24)。工作原理当一个共享变量被volatile修饰后它会具备两个关键特性内存可见性保证线程对这个变量的所有读写操作都会被直接提交到主内存中执行每次读取变量时都会直接从主内存拉取最新值彻底跳过工作内存缓存环节保证其他线程能立即感知到变量的最新变化。禁止指令重排序通过在底层插入内存屏障禁止编译器和 CPU 对该变量的读写操作指令进行重排序优化保证程序的执行顺序与代码编写顺序完全一致。适用场景volatile的轻量级特性决定了它有自己的特定适用场景不能替代synchronized一写多读场景只有一个线程修改共享变量其他多个线程并发读取变量值。此时volatile可以保证读线程能立即获取到变量的最新值。状态标记位场景共享变量作为判断业务状态的标志位使用。比如下面的开关控制示例在需要及时响应状态变化的场景下非常常用。单例模式的双重检查锁定需要结合volatile禁止指令重排序的特性保证实例化过程的执行顺序不会被调整避免其他线程获取到未完全初始化的对象。代码示例下面是一个使用volatile修饰开关标志位的典型案例确保线程能实时感知到标志位的状态变化public class VolatileDemo { #x20; // 使用volatile修饰共享变量保证可见性和禁止指令重排序 #x20; private static volatile boolean flag false; #x20; public static void main(String\[] args) throws InterruptedException { #x20; // 启动读线程等待flag标志位变为true #x20; Thread readerThread new Thread(() - { #x20; while (!flag) { #x20; // 循环等待直到flag变为true #x20; } #x20; System.out.println(读线程感知到flag状态变化开始执行后续业务逻辑); #x20; }); #x20; // 启动写线程修改flag标志位的值 #x20; Thread writerThread new Thread(() - { #x20; try { #x20; // 模拟业务处理耗时休眠1秒 #x20; Thread.sleep(1000); #x20; } catch (InterruptedException e) { #x20; e.printStackTrace(); #x20; } #x20; // 修改volatile变量的值会立即同步到主内存中 #x20; flag true; #x20; System.out.println(写线程已修改flag状态为true); #x20; }); #x20; // 启动两个线程 #x20; readerThread.start(); #x20; writerThread.start(); #x20; // 等待写线程执行完成 #x20; writerThread.join(); #x20; // 等待读线程执行完成 #x20; readerThread.join(); #x20; System.out.println(所有线程执行结束); #x20; } }注意事项需要特别强调的是volatile无法保证复合操作的原子性比如count这类 “读 - 改 - 写” 三步复合操作。因此在多个线程同时执行写操作的场景下volatile无法替代synchronized必须使用锁机制或原子类来保证线程安全(24)。2.3 基础方案的局限与不足synchronized和volatile虽然可以解决大部分简单场景下的线程安全问题但在中高并发、业务逻辑复杂的场景下存在着明显的局限性无法满足精细化的并发控制需求灵活性不足synchronized的锁机制无法被中断也无法设置获取锁的超时时间。线程如果长期获取不到锁就会一直处于阻塞状态无法主动响应中断请求在高并发场景下这很容易导致大量线程堆积进而引发系统雪崩。缺少高级功能synchronized底层的锁机制是基于对象的监视器锁实现的它无法实现公平锁机制也不具备读写锁分离等高级同步能力难以支撑对并发吞吐量要求较高的业务场景。粒度控制有限synchronized的锁粒度控制相对比较粗糙。虽然可以通过同步代码块来缩小锁范围但如果业务逻辑复杂锁粒度仍然难以精细化控制容易出现锁范围过大、并发度过低的情况。性能瓶颈在低竞争场景下synchronized的性能表现已经足够优秀但在高竞争场景下大量线程会阻塞等待锁导致频繁的线程上下文切换性能会出现显著下降。这些局限在高并发场景下会被进一步放大直接推动了 JUC 包中更灵活的高阶并发同步工具的诞生。三、高阶解决方案JUC 包并发工具java.util.concurrentJUC包是 Java 5 引入的一套高阶并发编程工具库提供了更灵活、更强大的并发控制机制弥补了基础同步关键字的不足。其中最核心的几个组件是Lock接口与ReentrantLock显式锁、原子类Atomic、以及其他用于线程间协作的同步工具类。3.1 Lock 接口与 ReentrantLock 显式锁Lock接口是 JUC 包中显式锁的核心抽象它的实现类ReentrantLock可重入锁提供了比synchronized更灵活、更精细化的锁控制能力。主要特性可重入性和synchronized一样ReentrantLock支持可重入锁 —— 同一个线程可以重复获取同一把锁避免线程自己阻塞自己的死锁问题。可中断等待支持在等待获取锁的过程中响应线程中断信号让线程可以主动取消锁获取请求避免永久阻塞。超时获取锁支持设置获取锁的最长等待时间一旦超过这个时间线程会自动放弃锁获取请求避免无限期阻塞。公平锁与非公平锁可以在构造方法中通过参数指定锁的公平性。公平锁会严格按照线程请求锁的顺序分配锁保证所有线程有机会获取锁非公平锁则允许线程在锁释放时直接尝试抢占锁不必遵循 FIFO 队列规则这也是默认模式。多个 Condition 条件可以通过newCondition()方法创建多个不同的条件对象实现线程间的精准唤醒而不是像synchronized那样随机唤醒所有等待线程。基本用法ReentrantLock的使用范式相对固定必须严格遵循 “加锁 - try-finally 解锁” 的流程确保锁一定会被释放避免死锁风险import java.util.concurrent.locks.Lock; import java.util.concurrent.locks.ReentrantLock; public class ReentrantLockDemo { #x20; // 创建显式锁对象默认是非公平锁 #x20; private final Lock lock new ReentrantLock(); #x20; private int count 0; #x20; public void increment() { #x20; // 1. 加锁 #x20; lock.lock(); #x20; try { #x20; // 2. 临界区业务逻辑对共享资源进行操作 #x20; count; #x20; } finally { #x20; // 3. 释放锁必须在finally块中执行确保锁一定会被释放 #x20; lock.unlock(); #x20; } #x20; } #x20; // 尝试非阻塞获取锁的高级用法 #x20; public boolean tryIncrement() { #x20; // 尝试获取锁立即返回获取结果不会阻塞线程 #x20; if (lock.tryLock()) { #x20; try { #x20; count; #x20; return true; #x20; } finally { #x20; lock.unlock(); #x20; } #x20; } #x20; // 获取锁失败直接返回不会阻塞 #x20; return false; #x20; } }高级功能示例Condition 实现精准唤醒ReentrantLock的Condition条件功能可以实现比synchronized更精准的线程间通信。下面通过一个简单的生产者 - 益者模型示例展示如何使用多个Condition对象实现精准的线程唤醒import java.util.concurrent.locks.Condition; import java.util.concurrent.locks.Lock; import java.util.concurrent.locks.ReentrantLock; public class ConditionDemo { #x20; private final Lock lock new ReentrantLock(); #x20; // 定义两个条件对象队列不满、队列不空 #x20; private final Condition notFull lock.newCondition(); #x20; private final Condition notEmpty lock.newCondition(); #x20; private final Object\[] items new Object\[100]; // 固定长度的队列 #x20; private int putIdx, takeIdx, count; #x20; // 生产者方法往队列中添加元素 #x20; public void put(Object x) throws InterruptedException { #x20; lock.lock(); #x20; try { #x20; // 当队列已满时在notFull条件上等待直到队列有空闲位置 #x20; while (count items.length) { #x20; notFull.await(); #x20; } #x20; // 将元素放入队列 #x20; items\[putIdx] x; #x20; // 计算下一个放入位置循环复用队列空间 #x20; putIdx (putIdx 1) % items.length; #x20; // 元素放入后队列不为空唤醒在notEmpty条件上等待的消费者线程 #x20; count; #x20; notEmpty.signal(); #x20; } finally { #x20; lock.unlock(); #x20; } #x20; } #x20; // 消费者方法从队列中取出元素 #x20; public Object take() throws InterruptedException { #x20; lock.lock(); #x20; try { #x20; // 当队列为空时在notEmpty条件上等待直到队列中有元素 #x20; while (count 0) { #x20; notEmpty.await(); #x20; } #x20; // 从队列中取出元素 #x20; Object x items\[takeIdx]; #x20; // 计算下一个取出位置循环复用队列空间 #x20; takeIdx (takeIdx 1) % items.length; #x20; // 元素取出后队列有空闲位置唤醒在notFull条件上等待的生产者线程 #x20; count--; #x20; notFull.signal(); #x20; return x; #x20; } finally { #x20; lock.unlock(); #x20; } #x20; } }在这个案例中通过notFull和notEmpty两个不同的Condition条件对象实现了对生产者和消费者线程的精准唤醒当队列已满时生产者线程在notFull条件上等待当队列中有空闲位置时消费者线程会通过notFull.signal()精准唤醒等待中的生产者线程不会影响到其他消费者线程反之亦然。这比synchronized的notifyAll()随机唤醒所有线程的方式效率要高得多(50)。3.2 原子类Atomic与 CAS 无锁编程JUC 包中的java.util.concurrent.atomic原子类包提供了一套基于无锁编程思想的线程安全解决方案。它的底层不使用任何互斥锁而是通过 CASCompare-And-Swap机制来保证操作的原子性性能比使用互斥锁的方案更优。核心思想CAS 无锁机制CAS 是一种基于硬件指令级支持的乐观并发技术它的核心逻辑是三个关键参数VVariable待更新的共享变量内存地址EExpected线程读取到的变量预期旧值NNew线程希望写入的新值。CAS 的执行逻辑是一个完整的原子操作处理器会先判断内存中 V 的当前值是否等于线程读取时的预期值 E。如果相等说明这段时间内没有其他线程修改过这个变量处理器会将 V 的值原子性地更新为新值 N如果不相等说明有其他线程已经抢先修改了变量处理器会直接放弃本次更新操作不会执行任何写回动作。整个 CAS 过程完全无需加锁操作失败的线程可以通过自旋重试来重新尝试更新操作。这种无锁设计从根本上避免了线程阻塞和上下文切换的开销是现代并发编程中重要的一个优化方向(41)。底层实现原理在 Java 中原子类的 CAS 操作底层是通过sun.misc.Unsafe类的本地方法来实现的。这个类提供了一系列可以直接操作内存的底层方法其中就包含 CAS 操作的相关实现。以AtomicInteger类为例它的底层存储结构非常简单只有一个用volatile修饰的value属性用来存储共享变量的当前值。这个属性的内存偏移量会在静态代码块中通过Unsafe类的objectFieldOffset方法获取到。在执行 CAS 更新操作时底层会将这个偏移量、预期值、新值作为参数传递给Unsafe类的本地方法最终映射到底层 CPU 的cmpxchg原子指令由硬件保证整个比较更新过程的原子性。AtomicInteger类的部分核心源码如下public class AtomicInteger extends Number implements java.io.Serializable { #x20; private static final long serialVersionUID 6214790243416807050L; #x20; // 获取Unsafe类的实例用于执行底层CAS操作 #x20; private static final Unsafe unsafe Unsafe.getUnsafe(); #x20; // 存储变量值的value属性的内存偏移量 #x20; private static final long valueOffset; #x20; static { #x20; try { #x20; // 在静态代码块中获取value属性在内存中的偏移量 #x20; valueOffset unsafe.objectFieldOffset #x20; (AtomicInteger.class.getDeclaredField(value)); #x20; } catch (Exception ex) { throw new Error(ex); } #x20; } #x20; // 实际存储变量值的核心属性用volatile修饰保证可见性 #x20; private volatile int value; #x20; // 构造方法初始化value属性 #x20; public AtomicInteger(int initialValue) { #x20; value initialValue; #x20; } #x20; // 核心CAS方法原子性地更新变量值如果当前值等于预期值则更新为新值 #x20; public final boolean compareAndSet(int expect, int update) { #x20; return unsafe.compareAndSwapInt(this, valueOffset, expect, update); #x20; } }在 HotSpot JVM 中compareAndSwapInt这个本地方法会由 C 和汇编语言实现最终映射到不同架构下的 CPU 原子指令。例如在 x86 架构下底层使用lock cmpxchg指令实现 CAS 操作在 ARM 架构下底层使用LDREX STREX组合指令或直接使用 ARMv8.1 的 CAS 相关指令。这种硬件级别的原子指令支持是整个 CAS 操作原子性的根本保障确保了比较和更新操作不会被其他线程的执行指令打断(46)。常用原子类示例JUC 的原子类包提供了针对不同数据类型的原子类覆盖了绝大多数无锁场景下的需求。下面以AtomicInteger类为例展示原子类的基本用法import java.util.concurrent.atomic.AtomicInteger; public class AtomicIntegerDemo { #x20; // 创建AtomicInteger对象初始值为0 #x20; private static final AtomicInteger count new AtomicInteger(0); #x20; public static void main(String\[] args) throws InterruptedException { #x20; // 定义两个线程分别执行50000次自增操作 #x20; Thread t1 new Thread(() - { #x20; for (int i 0; i 50000; i) { #x20; // 原子性地将当前值加1返回更新后的新值 #x20; count.incrementAndGet(); #x20; } #x20; }); #x20; Thread t2 new Thread(() - { #x20; for (int i 0; i 50000; i) { #x20; count.incrementAndGet(); #x20; } #x20; }); #x20; // 启动两个线程 #x20; t1.start(); #x20; t2.start(); #x20; // 等待两个线程执行完成 #x20; t1.join(); #x20; t2.join(); #x20; // 输出最终结果理论上应该输出100000实际也确实如此 #x20; System.out.println(count的实际最终值 count.get()); #x20; } }在这个案例中我们用AtomicInteger类的incrementAndGet()原子自增方法替代了之前的非线程安全的count自增操作。基于 CAS 无锁机制的保证这个操作全程不会有任何线程阻塞也不会有任何更新丢失程序实际运行结果永远是正确的 100000。3.3 其他重要的 JUC 并发工具除了ReentrantLock锁和原子类这两类核心组件外JUC 包还提供了很多其他的并发工具类覆盖了不同场景下的线程安全需求简化了并发编程的开发难度ReadWriteLock 读写锁它的实现类是ReentrantReadWriteLock提供了读锁和写锁两种分离的锁机制。读锁是共享锁可以被多个线程同时持有写锁是排他锁同一时间只能被一个线程持有。在读多写少的业务场景下比如数据缓存、配置读取等使用读写锁分离可以大幅提升程序的并发吞吐量。BlockingQueue 阻塞队列这是一个支持线程间阻塞读写的线程安全队列其主要实现类有ArrayBlockingQueue、LinkedBlockingQueue等。阻塞队列的核心特性是当队列已满时生产者线程会自动阻塞直到队列有空闲位置当队列为空时消费者线程会自动阻塞直到队列中有新的元素放入。阻塞队列可以用来轻松实现生产者 - 消费者模式无需开发者手动控制线程的阻塞和唤醒。CountDownLatch 倒计时闸门它可以让一个或多个线程等待其他多个线程执行完成后再继续往后执行。CountDownLatch内部维护了一个计数器线程可以通过countDown()方法将计数器减 1需要等待的线程则通过await()方法阻塞等待直到计数器值变为 0所有等待的线程才会被唤醒继续执行。CyclicBarrier 循环屏障它可以让一组线程互相等待直到所有线程都到达某个共同的同步屏障点后再统一继续往下执行。和CountDownLatch不同的是CyclicBarrier可以被循环使用所有线程都到达屏障点后计数器会自动重置准备下一轮的同步等待。Semaphore 信号量它用来控制同时访问某个特定资源的线程数量限制实现流量控制的功能。Semaphore内部维护了一个许可集合线程通过acquire()方法获取许可如果许可已被分配完毕线程会进入阻塞等待状态线程通过release()方法释放许可将其归还给信号量允许等待的其他线程获取许可访问资源。这些工具类共同构成了 Java 并发编程的完整技术体系开发者可以根据实际业务场景的需求选择最合适的并发控制工具。四、性能对比测试与深度分析为了让开发者更清晰地掌握不同线程安全方案的性能差异以及各自的适用场景下面将通过几组典型的并发场景测试数据对synchronized、ReentrantLock和AtomicInteger这三种最常用的线程安全解决方案进行量化对比。4.1 测试环境与基准方法测试基准工具采用 Java Microbenchmark HarnessJMH作为基准测试框架这是 Oracle 官方提供的专门用于 Java 代码性能基准测试的工具它可以有效排除 JIT 编译、垃圾回收等外部因素对测试结果的干扰测试结果的精准度和可重复性都非常高。测试 JDK 版本使用 JDK 1.8u311这是目前生产环境中使用最广泛的 LTS 版本具有代表性。测试 CPU 配置Intel i7-10700K 8 核 16 线程CPU 主频为 3.8GHz测试过程中关闭了 CPU 的睿频和节能模式保证测试环境的稳定性。测试场景设计覆盖了从低竞争到高竞争的实际并发场景以锁竞争频率、锁持有时长为核心变量分别测试了单线程无竞争、4 线程低竞争、32 线程高竞争三种不同场景下的性能表现。测试指标以吞吐量为核心测试指标即单位时间内可以完成的操作次数单位为ops/s数值越高代表方案的性能表现越优。4.2 不同锁机制的吞吐量对比下面是基于 JMH 框架的基准测试结果汇总展示了三种方案在不同并发场景下的吞吐量表现场景synchronizedReentrantLockAtomicInteger单线程无竞争约 6250000 ops/s约 5000000 ops/s约 10000000 ops/s4 线程低竞争约 830000 ops/s约 910000 ops/s约 3200000 ops/s32 线程高竞争约 55000 ops/s约 154000 ops/s约 1200000 ops/s测试数据的原始来源及更详细的测试报告可参考官方并发基准测试结果JUC 性能对比测试报告(26)。4.3 场景化性能分析结论从测试结果可以清晰地看出三种线程安全方案的性能表现在不同场景下呈现出完全不同的趋势。结合这些数据可以得出以下针对性的性能分析结论单线程无竞争场景synchronized的性能表现最优其次是ReentrantLock二者的性能差距约为 20%。这是因为在无竞争场景下synchronized的锁升级机制会停留在偏向锁或轻量级锁阶段只需要经过少量的 CAS 操作即可完成加锁和解锁开销极小而ReentrantLock底层始终需要基于 AQS 框架执行 CAS 操作和状态变更本身的原子操作开销相对更高。AtomicInteger的性能表现最优远超另外两种锁方案。这是因为无锁编程的 CAS 操作没有任何线程阻塞和上下文切换开销只需要在用户态执行少量 CPU 指令即可完成开销远低于互斥锁的加锁解锁操作。低竞争场景4 线程synchronized和ReentrantLock的性能差距不大二者的吞吐量差异不超过 10%。这是因为在低竞争场景下synchronized的锁升级机制通常会停留在轻量级锁阶段性能损耗非常有限而ReentrantLock的非公平锁机制可以有效减少线程的阻塞等待概率表现也非常优秀。AtomicInteger的性能表现仍然领先比两种锁方案高出约 2-3 倍无锁编程的优势初步显现。高竞争场景32 线程及以上ReentrantLock的性能表现显著优于synchronized吞吐量差距达到近 3 倍。这是因为当竞争加剧时synchronized会升级为重量级锁需要频繁执行线程阻塞、唤醒、上下文切换等操作开销呈指数级上升而ReentrantLock基于 AQS 框架的 CAS 自旋等待机制可以有效减少线程阻塞的概率性能下降幅度明显更平缓。AtomicInteger的性能表现仍然是最优的比ReentrantLock高出约 6-7 倍比synchronized高出约 20 倍。这是因为高竞争场景下锁的开销会被急剧放大而无锁编程的 CAS 操作不会有任何线程阻塞和上下文切换性能优势会被进一步放大。需要强调的是性能测试结果并不是绝对的它高度依赖于具体的并发场景竞争激烈程度、锁持有时长、任务类型的不同都会导致测试结果出现不同幅度的变化。但从整体趋势上看这个测试结论代表了不同场景下的一般性性能表现规律(26)。五、线程安全方案选型指南与调优建议Java 的并发编程体系提供了如此多的线程安全解决方案在实际项目中开发者应该如何根据业务场景选择最合适的方案下面提供一套覆盖不同场景的选型决策标准和实用调优建议。5.1 技术选型决策树线程安全方案的技术选型应该从业务场景的并发需求、性能指标、代码复杂度、可维护性等多方面综合考虑。根据经验通常可以按照以下优先级顺序进行决策选择优先选择无锁方案如果业务场景允许优先使用原子类如AtomicInteger、LongAdder或volatile关键字。无锁方案没有任何线程阻塞和上下文切换开销能带来最高的并发吞吐量。适用场景低延迟的计数器、状态标志位、序号生成器等只涉及简单变量操作的场景。注意事项原子类仅适用于对单一变量的原子操作volatile仅能保证可见性和有序性二者都无法保证多步骤复合操作的原子性。其次选择synchronized关键字如果是简单的互斥同步场景并且不需要ReentrantLock的高级功能优先使用synchronized。它的语法更简洁不会引入额外的锁释放开销在 JDK 6 及以后JVM 对synchronized的锁优化非常彻底低竞争场景下的性能表现已经非常优异。适用场景方法级或代码块级的简单互斥同步、并发吞吐量要求不高的业务场景。注意事项不适合用在需要超时控制、可中断等待、以及极高并发的场景下。然后选择ReentrantLock显式锁如果synchronized无法满足需求比如需要获取超时控制、可中断等待、公平锁、或者多个 Condition 精准唤醒等高级功能优先使用ReentrantLock。它的锁机制更灵活在高竞争场景下的性能表现也比synchronized更稳定。适用场景高并发业务场景、需要精细化管理线程协作的场景、或者需要使用非公平锁提升吞吐量的场景。注意事项必须严格遵循try-finally范式释放锁确保即使临界区代码抛出异常锁也能被正常释放避免死锁。最后选择其他 JUC 并发工具如果上述方案都无法满足需求再根据具体的业务场景选择 JUC 包中的其他并发工具类。例如读多写少场景使用ReentrantReadWriteLock读写锁分离提升读操作并发度生产者 - 消费者场景使用BlockingQueue阻塞队列简化线程间的同步协作逻辑多线程任务协同场景使用CountDownLatch或CyclicBarrier实现线程间的批量同步等待流量控制场景使用Semaphore信号量限制同时访问特定资源的线程数量。5.2 锁优化实用建议不论使用哪种锁机制都可以通过以下的优化建议进一步降低锁的开销提升程序的并发吞吐量减少锁持有时间这是锁优化最核心的原则。在保证业务逻辑正确性的前提下应该尽量缩小锁的临界区范围只对涉及共享资源读写的核心代码进行加锁保护对于不涉及共享资源的业务逻辑完全可以移到临界区之外执行。这样可以有效减少其他线程的阻塞等待时间提升整体并发度。降低锁粒度如果业务场景允许可以将一个独占锁拆分为多个并行的细粒度锁将锁的竞争范围降低到最小。例如在业务场景允许的前提下可以将全局的单一锁拆分为按业务分片的多个独立锁或者使用ConcurrentHashMap的分段锁思想将锁竞争控制在最小范围内提升并发性能。选择合适的锁公平性非公平锁是ReentrantLock的默认模式它能减少线程切换的开销提升整体吞吐量公平锁会按照线程请求锁的顺序分配锁保证所有线程有机会获取锁但会带来额外的线程切换开销吞吐量相对较低。在大多数业务场景下建议使用非公平锁只有在对响应时间有严格要求、或者业务场景不允许线程饿死的情况下才使用公平锁。避免无谓的锁操作如果业务逻辑允许应该尽量避免使用锁优先使用原子类或其他无锁方案。对于只读的共享资源可以使用不加锁的线程安全类或者使用不可变对象彻底避免锁竞争。此外还可以通过锁消除、锁粗化等 JVM 级别的优化手段减少加锁的实际开销。使用高级并发工具替代基础锁读多写少场景下优先使用ReentrantReadWriteLock读写锁分离提升读操作的并发度需要对并发任务进行流量控制时使用Semaphore信号量需要在线程间进行精准的阻塞唤醒协作时使用BlockingQueue阻塞队列。这些工具类的封装性更好性能也比手动加锁更优。5.3 实际项目最佳实践结合大量实际项目的生产经验在使用 Java 并发编程工具时应该严格遵循以下几条最佳实践原则避免引入隐蔽的并发故障优先使用无锁方案只要业务场景允许应该优先使用原子类或volatile关键字而不是锁。无锁编程的性能上限更高也不会带来死锁等锁相关的风险。尽量缩小锁范围能使用同步代码块的场景就不要使用同步方法锁的临界区代码能少写就少写只对真正需要保护的共享资源操作进行加锁避免不必要的性能开销。ReentrantLock必须在finally块中释放锁使用ReentrantLock时必须严格遵循try-finally的加锁解锁范式 —— 在try代码块之外获取锁在finally代码块中释放锁。这样可以保证即使临界区代码抛出业务异常锁也能被正常释放不会导致死锁。尽量避免使用stop()、suspend()等废弃的线程控制方法这些方法是 JDK 早期提供的现在已经被标记为废弃状态。使用它们可能会导致线程在持有锁的情况下被强制中断或者导致线程长时间挂起进而引发死锁或资源不一致等问题。应该使用interrupt()方法或Condition条件的精准唤醒机制来实现线程的协作控制。优先使用并发容器而非手动加锁的同步容器JUC 包中提供了大量线程安全的并发容器比如ConcurrentHashMap、CopyOnWriteArrayList、ConcurrentLinkedQueue等。这些并发容器的内部已经通过精心的锁优化或无锁机制保证了线程安全而且性能比Collections.synchronizedXXX包装的同步容器更优。应该优先使用这些并发容器替代手动加锁的同步容器。并发编程代码必须经过性能测试和压力测试所有的并发代码在开发完成后不仅要在功能层面验证正确性还要在性能测试和压力测试环境下模拟生产级别的并发流量验证在高并发场景下的性能表现和数据一致性。只有经过充分的压测验证才能避免在生产环境中出现隐蔽的并发安全问题。六、总结Java 提供了一套完整的、覆盖从基础到高阶的线程安全解决方案从基础的synchronized关键字和volatile轻量级同步机制到高阶的ReentrantLock显式锁、原子类和 JUC 并发工具包开发者可以根据实际业务场景的并发需求灵活选择最合适的技术方案。通过本文的详细分析我们可以得出以下几条核心结论作为并发编程的选型参考原则线程安全的核心三要素是原子性、可见性和有序性任何一个并发控制方案都必须至少保证这三个要素中的一个或多个才能真正实现线程安全。无锁方案的性能优于锁方案在业务场景允许的前提下应该优先使用原子类或volatile关键字等无锁方案这类方案没有线程阻塞和上下文切换开销能支撑更高的并发吞吐量。锁方案中synchronized和ReentrantLock各有所长在低竞争、简单同步场景下synchronized的性能表现更优代码也更简洁在高竞争、需要精细化并发控制的场景下ReentrantLock的灵活性和性能表现更优。JUC 包提供了高阶并发控制的完整解决方案对于复杂的业务场景JUC 包中的ReentrantLock显式锁、原子类、阻塞队列、同步工具类可以充分满足开发需求简化并发编程的开发难度。作为 Java 开发者在实际业务中进行并发编程时不能只停留在使用 API 的层面而要深刻理解不同同步方案的底层原理、适用场景和性能差异。只有这样才能在保证线程安全的前提下最大化地提升程序的并发性能写出高可靠、高性能、可维护的并发编程代码。参考资料Java 官方并发编程文档Java Concurrency Multi-threading GuideJUC 包源码分析java.util.concurrent API 源码文档《Java 并发编程实战》Brian Goetz 等著机械工业出版社《Java 高并发编程详解》汪文君著机械工业出版社JMH 并发性能基准测试官方样例OpenJDK JMH SamplesReentrantLock 官方 API 文档Class ReentrantLock原子类底层实现原理深度解析Java Atomic Variables and CAS Java线程安全问题成因与全套解决方案（从基础到高阶）
Java 线程安全问题成因与全套解决方案从基础到高阶目录引言一、线程安全问题的本质与成因2.1 抢占式线程调度执行2.2 多线程修改同一共享变量2.3 非原子性操作2.4 内存可见性问题2.5 指令重排序2.6 典型问题代码示例二、基础解决方案synchronized 与 volatile2.1 synchronized 关键字2.2 volatile 关键字2.3 基础方案的局限与不足三、高阶解决方案JUC 包并发工具3.1 Lock 接口与 ReentrantLock 显式锁3.2 原子类Atomic与 CAS 无锁编程3.3 其他重要的 JUC 并发工具四、性能对比测试与深度分析4.1 测试环境与基准方法4.2 不同锁机制的吞吐量对比4.3 场景化性能分析结论五、线程安全方案选型指南与调优建议5.1 技术选型决策树5.2 锁优化实用建议5.3 实际项目最佳实践六、总结参考资料引言在当今互联网高并发、大数据量的业务场景下多线程并发编程已成为提升应用性能的核心手段。然而多线程犹如一把双刃剑在充分利用 CPU 资源、大幅提升程序响应速度的同时也带来了复杂的线程安全问题。这类问题隐蔽性极强、复现成本极高稍不注意就会导致数据错乱、业务逻辑异常甚至引发生产级别故障。Java 语言作为企业级应用的主流选型从基础的synchronized关键字到高阶的java.util.concurrent简称 JUC并发工具包提供了一套完整、覆盖不同场景的线程安全解决方案。但很多开发者尤其是初级工程师往往停留在 “会用 API” 的阶段对底层原理、适用边界和性能差异缺乏认知导致实际场景中出现各种并发 bug。本文将从线程安全问题的底层成因入手循序渐进地从基础语法级解决方案深入剖析到高阶 JUC 并发工具的底层设计与实战应用。通过大量可直接运行的代码示例、精准的性能对比数据和场景化的选型建议帮助不同阶段的开发者建立完整的并发编程知识体系在实际业务中精准规避线程安全陷阱。一、线程安全问题的本质与成因线程安全问题的本质是多线程环境下对共享资源的无序访问与操作冲突。其核心矛盾在于多线程需要共享资源完成业务协作但 CPU 的并行执行机制又会导致资源操作的顺序被打乱破坏数据的完整性与一致性(3)。要写出高可靠的并发代码必须先理解线程安全问题的五大核心成因以及它们是如何具体引发数据异常的。2.1 抢占式线程调度执行Java 线程的调度模式是抢占式执行—— 操作系统会依据线程优先级、CPU 时间片剩余情况等复杂逻辑随机调度线程执行没有任何固定的全局顺序。这意味着在一个多线程程序中各线程的执行起始时间、执行持续时长、以及线程切换的具体时机都是完全不可控的。这种随机性是所有线程安全问题的根源如果线程能完全按照预设的有序顺序执行或者采用单线程模式根本不会存在并发冲突也就不会有线程安全问题(17)。2.2 多线程修改同一共享变量线程安全问题的另一前提条件是多个线程同时对同一个共享变量执行修改操作。这里的 “共享变量”涵盖了成员变量、静态变量、堆内存中的对象资源等这些资源可以被多个线程同时访问。如果多个线程仅对共享变量执行读取操作或者各线程操作的是不同的变量副本不会引发任何数据冲突但当一个变量同时被多个线程读写时就极有可能产生并发冲突导致最终数据出现偏差(3)。2.3 非原子性操作“原子性” 是指一个操作或多个操作序列不可分割要么全部执行完成要么完全不执行中途不会被任何线程调度打断。在 Java 中很多看似 “独立” 的操作底层实际上是由多条 CPU 指令拼接而成的并不具备原子性。最典型的就是count自增操作这行代码在语法层面是一个整体但在底层 CPU 指令层面实际需要执行三个完整步骤从主内存读取count的当前工作值对读取到的值执行 1 运算将计算后的新值写回主内存如果缺乏同步机制保证多个线程可能在同一时间点交错执行这三个步骤最终导致更新操作丢失数据结果出现偏差(6)。这也是多线程下计数器结果不准的核心原因。2.4 内存可见性问题内存可见性是指一个线程修改了共享变量的值后其他线程能否立即感知到这一变化。导致可见性问题的根源是 Java 内存模型JMM设计的工作内存与主内存的交互机制。为了提升整体执行效率每个线程都拥有独立的工作内存可以理解为 CPU 的各级缓存线程对共享变量的所有读写操作都需要先将主内存中的变量副本读取到工作内存修改后再同步回主内存。如果多个线程各自缓存了共享变量的工作副本一个线程将新值写入主内存后其他线程可能仍然在使用工作内存中的旧副本无法第一时间获取到最新值这就产生了严重的内存可见性问题(1)。在需要及时感知变量状态变化的场景下这类问题会导致业务逻辑异常。2.5 指令重排序为了最大化 CPU 执行效率编译器、JVM 和 CPU 本身都会在保证单线程执行结果不受影响的前提下对实际的指令执行顺序进行重新编排优化。比如程序中写在后面的代码指令可能被调整到前面执行无数据依赖的多条指令可能会被并行执行。这种重排序优化在单线程环境下不会产生任何问题但在多线程环境下线程间没有数据执行依赖重排序就可能会导致程序的实际执行逻辑与预期逻辑产生巨大偏差。比如一个典型的场景线程 A 先执行了变量初始化操作再将标志位设置为 true但由于指令重排序实际执行时线程 A 可能先将标志位设置为 true随后才执行变量初始化操作。此时线程 B 如果看到标志位为 true就会去读取尚未完全初始化的变量直接触发空指针异常或数据错乱这也是指令重排序优化带来的典型线程安全问题(7)。2.6 典型问题代码示例下面通过一个经典的多线程计数器案例复现上述五大成因共同导致的线程安全问题public class ThreadSafetyDemo { #x20; // 共享静态变量 #x20; public static int count 0; #x20; public static void main(String\[] args) throws InterruptedException { #x20; // 定义两个线程分别执行50000次自增操作 #x20; Thread t1 new Thread(() - { #x20; for (int i 0; i 50000; i) { #x20; count; #x20; } #x20; }); #x20; Thread t2 new Thread(() - { #x20; for (int i 0; i 50000; i) { #x20; count; #x20; } #x20; }); #x20; // 启动两个线程 #x20; t1.start(); #x20; t2.start(); #x20; // 主线程等待t1、t2执行完成后再执行后续输出逻辑 #x20; t1.join(); #x20; t2.join(); #x20; // 理论上应该输出100000但实际运行结果几乎都小于预期值 #x20; System.out.println(count的实际最终值 count); #x20; } }代码分析在这个案例中两个线程t1和t2分别对共享变量count执行 50000 次自增操作正常逻辑下程序应该输出 100000。但实际运行时由于以下多重因素的叠加结果几乎永远达不到预期值抢占式执行导致线程切换不可控两个线程同时修改同一个共享变量自增操作count不具备原子性线程间缓存导致内存可见性问题指令重排序进一步加剧了操作序列的混乱。这五种因素的叠加直接导致部分自增操作的执行结果被覆盖更新操作丢失最终的输出结果小于 100000。这是一个非常典型的线程安全问题清晰地展示了缺乏同步控制时多线程程序的共享资源访问会出现严重偏差(19)。二、基础解决方案synchronized 与 volatile针对线程安全的三大核心维度 —— 原子性、可见性、有序性Java 在语言层面提供了两个最基础的同步解决方案synchronized关键字和volatile关键字。二者的组合可以覆盖大多数简单并发场景下的线程安全需求。2.1 synchronized 关键字synchronized是 Java 内置的基于悲观锁思想的同步机制它可以保证同一时间点只有一个线程能进入临界区访问共享资源的代码块确保对共享资源操作的原子性、可见性和有序性是解决线程安全问题最基础的手段(22)。主要用法synchronized有三种不同的使用方式分别对应不同的锁粒度和锁定范围修饰实例方法锁住当前实例对象同一时间只有一个线程能调用该实例的被synchronized修饰的方法。public synchronized void increment() { #x20; count; // 原子性执行不会出现数据错乱 }修饰静态方法锁住当前类的 Class 对象所有该类的实例对象共用同一把锁即使创建多个实例也只有一个线程能执行该静态方法。public static synchronized void staticIncrement() { #x20; count; // 原子性执行不会出现数据错乱 }修饰同步代码块显式指定锁对象锁粒度更灵活可以选择只对需要同步的代码片段加锁避免不必要的性能开销这也是官方推荐的使用方式。public void safeIncrement() { #x20; // 显式指定锁对象通常是共享资源的Class对象或this实例 #x20; synchronized (this) { #x20; count; // 原子性执行不会出现数据错乱 #x20; } }工作原理synchronized的底层是通过对象监视器Monitor机制实现同步的每个 Java 对象在底层都关联一个唯一的 Monitor 锁。当线程尝试获取锁时JVM 会通过 CAS 操作尝试修改对象头的 Mark Word 标记字段如果获取锁成功线程会记录下自己的锁持有状态如果获取失败线程会直接进入同步队列进入阻塞等待状态。在 JDK 6 及以后JVM 对synchronized进行了非常彻底的锁优化引入了包含偏向锁、轻量级锁、重量级锁、自适应自旋、锁消除、锁粗化在内的完整锁升级机制。这些优化极大地降低了加锁和解锁的操作开销让synchronized在低竞争场景下的性能得到了质的提升甚至在部分场景下比显式锁的表现更优秀(30)。2.2 volatile 关键字volatile是 Java 提供的另一个轻量级同步机制它的主要作用是保证变量的内存可见性和禁止指令重排序但不具备原子性保证无法单独解决非原子性操作带来的线程安全问题(24)。工作原理当一个共享变量被volatile修饰后它会具备两个关键特性内存可见性保证线程对这个变量的所有读写操作都会被直接提交到主内存中执行每次读取变量时都会直接从主内存拉取最新值彻底跳过工作内存缓存环节保证其他线程能立即感知到变量的最新变化。禁止指令重排序通过在底层插入内存屏障禁止编译器和 CPU 对该变量的读写操作指令进行重排序优化保证程序的执行顺序与代码编写顺序完全一致。适用场景volatile的轻量级特性决定了它有自己的特定适用场景不能替代synchronized一写多读场景只有一个线程修改共享变量其他多个线程并发读取变量值。此时volatile可以保证读线程能立即获取到变量的最新值。状态标记位场景共享变量作为判断业务状态的标志位使用。比如下面的开关控制示例在需要及时响应状态变化的场景下非常常用。单例模式的双重检查锁定需要结合volatile禁止指令重排序的特性保证实例化过程的执行顺序不会被调整避免其他线程获取到未完全初始化的对象。代码示例下面是一个使用volatile修饰开关标志位的典型案例确保线程能实时感知到标志位的状态变化public class VolatileDemo { #x20; // 使用volatile修饰共享变量保证可见性和禁止指令重排序 #x20; private static volatile boolean flag false; #x20; public static void main(String\[] args) throws InterruptedException { #x20; // 启动读线程等待flag标志位变为true #x20; Thread readerThread new Thread(() - { #x20; while (!flag) { #x20; // 循环等待直到flag变为true #x20; } #x20; System.out.println(读线程感知到flag状态变化开始执行后续业务逻辑); #x20; }); #x20; // 启动写线程修改flag标志位的值 #x20; Thread writerThread new Thread(() - { #x20; try { #x20; // 模拟业务处理耗时休眠1秒 #x20; Thread.sleep(1000); #x20; } catch (InterruptedException e) { #x20; e.printStackTrace(); #x20; } #x20; // 修改volatile变量的值会立即同步到主内存中 #x20; flag true; #x20; System.out.println(写线程已修改flag状态为true); #x20; }); #x20; // 启动两个线程 #x20; readerThread.start(); #x20; writerThread.start(); #x20; // 等待写线程执行完成 #x20; writerThread.join(); #x20; // 等待读线程执行完成 #x20; readerThread.join(); #x20; System.out.println(所有线程执行结束); #x20; } }注意事项需要特别强调的是volatile无法保证复合操作的原子性比如count这类 “读 - 改 - 写” 三步复合操作。因此在多个线程同时执行写操作的场景下volatile无法替代synchronized必须使用锁机制或原子类来保证线程安全(24)。2.3 基础方案的局限与不足synchronized和volatile虽然可以解决大部分简单场景下的线程安全问题但在中高并发、业务逻辑复杂的场景下存在着明显的局限性无法满足精细化的并发控制需求灵活性不足synchronized的锁机制无法被中断也无法设置获取锁的超时时间。线程如果长期获取不到锁就会一直处于阻塞状态无法主动响应中断请求在高并发场景下这很容易导致大量线程堆积进而引发系统雪崩。缺少高级功能synchronized底层的锁机制是基于对象的监视器锁实现的它无法实现公平锁机制也不具备读写锁分离等高级同步能力难以支撑对并发吞吐量要求较高的业务场景。粒度控制有限synchronized的锁粒度控制相对比较粗糙。虽然可以通过同步代码块来缩小锁范围但如果业务逻辑复杂锁粒度仍然难以精细化控制容易出现锁范围过大、并发度过低的情况。性能瓶颈在低竞争场景下synchronized的性能表现已经足够优秀但在高竞争场景下大量线程会阻塞等待锁导致频繁的线程上下文切换性能会出现显著下降。这些局限在高并发场景下会被进一步放大直接推动了 JUC 包中更灵活的高阶并发同步工具的诞生。三、高阶解决方案JUC 包并发工具java.util.concurrentJUC包是 Java 5 引入的一套高阶并发编程工具库提供了更灵活、更强大的并发控制机制弥补了基础同步关键字的不足。其中最核心的几个组件是Lock接口与ReentrantLock显式锁、原子类Atomic、以及其他用于线程间协作的同步工具类。3.1 Lock 接口与 ReentrantLock 显式锁Lock接口是 JUC 包中显式锁的核心抽象它的实现类ReentrantLock可重入锁提供了比synchronized更灵活、更精细化的锁控制能力。主要特性可重入性和synchronized一样ReentrantLock支持可重入锁 —— 同一个线程可以重复获取同一把锁避免线程自己阻塞自己的死锁问题。可中断等待支持在等待获取锁的过程中响应线程中断信号让线程可以主动取消锁获取请求避免永久阻塞。超时获取锁支持设置获取锁的最长等待时间一旦超过这个时间线程会自动放弃锁获取请求避免无限期阻塞。公平锁与非公平锁可以在构造方法中通过参数指定锁的公平性。公平锁会严格按照线程请求锁的顺序分配锁保证所有线程有机会获取锁非公平锁则允许线程在锁释放时直接尝试抢占锁不必遵循 FIFO 队列规则这也是默认模式。多个 Condition 条件可以通过newCondition()方法创建多个不同的条件对象实现线程间的精准唤醒而不是像synchronized那样随机唤醒所有等待线程。基本用法ReentrantLock的使用范式相对固定必须严格遵循 “加锁 - try-finally 解锁” 的流程确保锁一定会被释放避免死锁风险import java.util.concurrent.locks.Lock; import java.util.concurrent.locks.ReentrantLock; public class ReentrantLockDemo { #x20; // 创建显式锁对象默认是非公平锁 #x20; private final Lock lock new ReentrantLock(); #x20; private int count 0; #x20; public void increment() { #x20; // 1. 加锁 #x20; lock.lock(); #x20; try { #x20; // 2. 临界区业务逻辑对共享资源进行操作 #x20; count; #x20; } finally { #x20; // 3. 释放锁必须在finally块中执行确保锁一定会被释放 #x20; lock.unlock(); #x20; } #x20; } #x20; // 尝试非阻塞获取锁的高级用法 #x20; public boolean tryIncrement() { #x20; // 尝试获取锁立即返回获取结果不会阻塞线程 #x20; if (lock.tryLock()) { #x20; try { #x20; count; #x20; return true; #x20; } finally { #x20; lock.unlock(); #x20; } #x20; } #x20; // 获取锁失败直接返回不会阻塞 #x20; return false; #x20; } }高级功能示例Condition 实现精准唤醒ReentrantLock的Condition条件功能可以实现比synchronized更精准的线程间通信。下面通过一个简单的生产者 - 益者模型示例展示如何使用多个Condition对象实现精准的线程唤醒import java.util.concurrent.locks.Condition; import java.util.concurrent.locks.Lock; import java.util.concurrent.locks.ReentrantLock; public class ConditionDemo { #x20; private final Lock lock new ReentrantLock(); #x20; // 定义两个条件对象队列不满、队列不空 #x20; private final Condition notFull lock.newCondition(); #x20; private final Condition notEmpty lock.newCondition(); #x20; private final Object\[] items new Object\[100]; // 固定长度的队列 #x20; private int putIdx, takeIdx, count; #x20; // 生产者方法往队列中添加元素 #x20; public void put(Object x) throws InterruptedException { #x20; lock.lock(); #x20; try { #x20; // 当队列已满时在notFull条件上等待直到队列有空闲位置 #x20; while (count items.length) { #x20; notFull.await(); #x20; } #x20; // 将元素放入队列 #x20; items\[putIdx] x; #x20; // 计算下一个放入位置循环复用队列空间 #x20; putIdx (putIdx 1) % items.length; #x20; // 元素放入后队列不为空唤醒在notEmpty条件上等待的消费者线程 #x20; count; #x20; notEmpty.signal(); #x20; } finally { #x20; lock.unlock(); #x20; } #x20; } #x20; // 消费者方法从队列中取出元素 #x20; public Object take() throws InterruptedException { #x20; lock.lock(); #x20; try { #x20; // 当队列为空时在notEmpty条件上等待直到队列中有元素 #x20; while (count 0) { #x20; notEmpty.await(); #x20; } #x20; // 从队列中取出元素 #x20; Object x items\[takeIdx]; #x20; // 计算下一个取出位置循环复用队列空间 #x20; takeIdx (takeIdx 1) % items.length; #x20; // 元素取出后队列有空闲位置唤醒在notFull条件上等待的生产者线程 #x20; count--; #x20; notFull.signal(); #x20; return x; #x20; } finally { #x20; lock.unlock(); #x20; } #x20; } }在这个案例中通过notFull和notEmpty两个不同的Condition条件对象实现了对生产者和消费者线程的精准唤醒当队列已满时生产者线程在notFull条件上等待当队列中有空闲位置时消费者线程会通过notFull.signal()精准唤醒等待中的生产者线程不会影响到其他消费者线程反之亦然。这比synchronized的notifyAll()随机唤醒所有线程的方式效率要高得多(50)。3.2 原子类Atomic与 CAS 无锁编程JUC 包中的java.util.concurrent.atomic原子类包提供了一套基于无锁编程思想的线程安全解决方案。它的底层不使用任何互斥锁而是通过 CASCompare-And-Swap机制来保证操作的原子性性能比使用互斥锁的方案更优。核心思想CAS 无锁机制CAS 是一种基于硬件指令级支持的乐观并发技术它的核心逻辑是三个关键参数VVariable待更新的共享变量内存地址EExpected线程读取到的变量预期旧值NNew线程希望写入的新值。CAS 的执行逻辑是一个完整的原子操作处理器会先判断内存中 V 的当前值是否等于线程读取时的预期值 E。如果相等说明这段时间内没有其他线程修改过这个变量处理器会将 V 的值原子性地更新为新值 N如果不相等说明有其他线程已经抢先修改了变量处理器会直接放弃本次更新操作不会执行任何写回动作。整个 CAS 过程完全无需加锁操作失败的线程可以通过自旋重试来重新尝试更新操作。这种无锁设计从根本上避免了线程阻塞和上下文切换的开销是现代并发编程中重要的一个优化方向(41)。底层实现原理在 Java 中原子类的 CAS 操作底层是通过sun.misc.Unsafe类的本地方法来实现的。这个类提供了一系列可以直接操作内存的底层方法其中就包含 CAS 操作的相关实现。以AtomicInteger类为例它的底层存储结构非常简单只有一个用volatile修饰的value属性用来存储共享变量的当前值。这个属性的内存偏移量会在静态代码块中通过Unsafe类的objectFieldOffset方法获取到。在执行 CAS 更新操作时底层会将这个偏移量、预期值、新值作为参数传递给Unsafe类的本地方法最终映射到底层 CPU 的cmpxchg原子指令由硬件保证整个比较更新过程的原子性。AtomicInteger类的部分核心源码如下public class AtomicInteger extends Number implements java.io.Serializable { #x20; private static final long serialVersionUID 6214790243416807050L; #x20; // 获取Unsafe类的实例用于执行底层CAS操作 #x20; private static final Unsafe unsafe Unsafe.getUnsafe(); #x20; // 存储变量值的value属性的内存偏移量 #x20; private static final long valueOffset; #x20; static { #x20; try { #x20; // 在静态代码块中获取value属性在内存中的偏移量 #x20; valueOffset unsafe.objectFieldOffset #x20; (AtomicInteger.class.getDeclaredField(value)); #x20; } catch (Exception ex) { throw new Error(ex); } #x20; } #x20; // 实际存储变量值的核心属性用volatile修饰保证可见性 #x20; private volatile int value; #x20; // 构造方法初始化value属性 #x20; public AtomicInteger(int initialValue) { #x20; value initialValue; #x20; } #x20; // 核心CAS方法原子性地更新变量值如果当前值等于预期值则更新为新值 #x20; public final boolean compareAndSet(int expect, int update) { #x20; return unsafe.compareAndSwapInt(this, valueOffset, expect, update); #x20; } }在 HotSpot JVM 中compareAndSwapInt这个本地方法会由 C 和汇编语言实现最终映射到不同架构下的 CPU 原子指令。例如在 x86 架构下底层使用lock cmpxchg指令实现 CAS 操作在 ARM 架构下底层使用LDREX STREX组合指令或直接使用 ARMv8.1 的 CAS 相关指令。这种硬件级别的原子指令支持是整个 CAS 操作原子性的根本保障确保了比较和更新操作不会被其他线程的执行指令打断(46)。常用原子类示例JUC 的原子类包提供了针对不同数据类型的原子类覆盖了绝大多数无锁场景下的需求。下面以AtomicInteger类为例展示原子类的基本用法import java.util.concurrent.atomic.AtomicInteger; public class AtomicIntegerDemo { #x20; // 创建AtomicInteger对象初始值为0 #x20; private static final AtomicInteger count new AtomicInteger(0); #x20; public static void main(String\[] args) throws InterruptedException { #x20; // 定义两个线程分别执行50000次自增操作 #x20; Thread t1 new Thread(() - { #x20; for (int i 0; i 50000; i) { #x20; // 原子性地将当前值加1返回更新后的新值 #x20; count.incrementAndGet(); #x20; } #x20; }); #x20; Thread t2 new Thread(() - { #x20; for (int i 0; i 50000; i) { #x20; count.incrementAndGet(); #x20; } #x20; }); #x20; // 启动两个线程 #x20; t1.start(); #x20; t2.start(); #x20; // 等待两个线程执行完成 #x20; t1.join(); #x20; t2.join(); #x20; // 输出最终结果理论上应该输出100000实际也确实如此 #x20; System.out.println(count的实际最终值 count.get()); #x20; } }在这个案例中我们用AtomicInteger类的incrementAndGet()原子自增方法替代了之前的非线程安全的count自增操作。基于 CAS 无锁机制的保证这个操作全程不会有任何线程阻塞也不会有任何更新丢失程序实际运行结果永远是正确的 100000。3.3 其他重要的 JUC 并发工具除了ReentrantLock锁和原子类这两类核心组件外JUC 包还提供了很多其他的并发工具类覆盖了不同场景下的线程安全需求简化了并发编程的开发难度ReadWriteLock 读写锁它的实现类是ReentrantReadWriteLock提供了读锁和写锁两种分离的锁机制。读锁是共享锁可以被多个线程同时持有写锁是排他锁同一时间只能被一个线程持有。在读多写少的业务场景下比如数据缓存、配置读取等使用读写锁分离可以大幅提升程序的并发吞吐量。BlockingQueue 阻塞队列这是一个支持线程间阻塞读写的线程安全队列其主要实现类有ArrayBlockingQueue、LinkedBlockingQueue等。阻塞队列的核心特性是当队列已满时生产者线程会自动阻塞直到队列有空闲位置当队列为空时消费者线程会自动阻塞直到队列中有新的元素放入。阻塞队列可以用来轻松实现生产者 - 消费者模式无需开发者手动控制线程的阻塞和唤醒。CountDownLatch 倒计时闸门它可以让一个或多个线程等待其他多个线程执行完成后再继续往后执行。CountDownLatch内部维护了一个计数器线程可以通过countDown()方法将计数器减 1需要等待的线程则通过await()方法阻塞等待直到计数器值变为 0所有等待的线程才会被唤醒继续执行。CyclicBarrier 循环屏障它可以让一组线程互相等待直到所有线程都到达某个共同的同步屏障点后再统一继续往下执行。和CountDownLatch不同的是CyclicBarrier可以被循环使用所有线程都到达屏障点后计数器会自动重置准备下一轮的同步等待。Semaphore 信号量它用来控制同时访问某个特定资源的线程数量限制实现流量控制的功能。Semaphore内部维护了一个许可集合线程通过acquire()方法获取许可如果许可已被分配完毕线程会进入阻塞等待状态线程通过release()方法释放许可将其归还给信号量允许等待的其他线程获取许可访问资源。这些工具类共同构成了 Java 并发编程的完整技术体系开发者可以根据实际业务场景的需求选择最合适的并发控制工具。四、性能对比测试与深度分析为了让开发者更清晰地掌握不同线程安全方案的性能差异以及各自的适用场景下面将通过几组典型的并发场景测试数据对synchronized、ReentrantLock和AtomicInteger这三种最常用的线程安全解决方案进行量化对比。4.1 测试环境与基准方法测试基准工具采用 Java Microbenchmark HarnessJMH作为基准测试框架这是 Oracle 官方提供的专门用于 Java 代码性能基准测试的工具它可以有效排除 JIT 编译、垃圾回收等外部因素对测试结果的干扰测试结果的精准度和可重复性都非常高。测试 JDK 版本使用 JDK 1.8u311这是目前生产环境中使用最广泛的 LTS 版本具有代表性。测试 CPU 配置Intel i7-10700K 8 核 16 线程CPU 主频为 3.8GHz测试过程中关闭了 CPU 的睿频和节能模式保证测试环境的稳定性。测试场景设计覆盖了从低竞争到高竞争的实际并发场景以锁竞争频率、锁持有时长为核心变量分别测试了单线程无竞争、4 线程低竞争、32 线程高竞争三种不同场景下的性能表现。测试指标以吞吐量为核心测试指标即单位时间内可以完成的操作次数单位为ops/s数值越高代表方案的性能表现越优。4.2 不同锁机制的吞吐量对比下面是基于 JMH 框架的基准测试结果汇总展示了三种方案在不同并发场景下的吞吐量表现场景synchronizedReentrantLockAtomicInteger单线程无竞争约 6250000 ops/s约 5000000 ops/s约 10000000 ops/s4 线程低竞争约 830000 ops/s约 910000 ops/s约 3200000 ops/s32 线程高竞争约 55000 ops/s约 154000 ops/s约 1200000 ops/s测试数据的原始来源及更详细的测试报告可参考官方并发基准测试结果JUC 性能对比测试报告(26)。4.3 场景化性能分析结论从测试结果可以清晰地看出三种线程安全方案的性能表现在不同场景下呈现出完全不同的趋势。结合这些数据可以得出以下针对性的性能分析结论单线程无竞争场景synchronized的性能表现最优其次是ReentrantLock二者的性能差距约为 20%。这是因为在无竞争场景下synchronized的锁升级机制会停留在偏向锁或轻量级锁阶段只需要经过少量的 CAS 操作即可完成加锁和解锁开销极小而ReentrantLock底层始终需要基于 AQS 框架执行 CAS 操作和状态变更本身的原子操作开销相对更高。AtomicInteger的性能表现最优远超另外两种锁方案。这是因为无锁编程的 CAS 操作没有任何线程阻塞和上下文切换开销只需要在用户态执行少量 CPU 指令即可完成开销远低于互斥锁的加锁解锁操作。低竞争场景4 线程synchronized和ReentrantLock的性能差距不大二者的吞吐量差异不超过 10%。这是因为在低竞争场景下synchronized的锁升级机制通常会停留在轻量级锁阶段性能损耗非常有限而ReentrantLock的非公平锁机制可以有效减少线程的阻塞等待概率表现也非常优秀。AtomicInteger的性能表现仍然领先比两种锁方案高出约 2-3 倍无锁编程的优势初步显现。高竞争场景32 线程及以上ReentrantLock的性能表现显著优于synchronized吞吐量差距达到近 3 倍。这是因为当竞争加剧时synchronized会升级为重量级锁需要频繁执行线程阻塞、唤醒、上下文切换等操作开销呈指数级上升而ReentrantLock基于 AQS 框架的 CAS 自旋等待机制可以有效减少线程阻塞的概率性能下降幅度明显更平缓。AtomicInteger的性能表现仍然是最优的比ReentrantLock高出约 6-7 倍比synchronized高出约 20 倍。这是因为高竞争场景下锁的开销会被急剧放大而无锁编程的 CAS 操作不会有任何线程阻塞和上下文切换性能优势会被进一步放大。需要强调的是性能测试结果并不是绝对的它高度依赖于具体的并发场景竞争激烈程度、锁持有时长、任务类型的不同都会导致测试结果出现不同幅度的变化。但从整体趋势上看这个测试结论代表了不同场景下的一般性性能表现规律(26)。五、线程安全方案选型指南与调优建议Java 的并发编程体系提供了如此多的线程安全解决方案在实际项目中开发者应该如何根据业务场景选择最合适的方案下面提供一套覆盖不同场景的选型决策标准和实用调优建议。5.1 技术选型决策树线程安全方案的技术选型应该从业务场景的并发需求、性能指标、代码复杂度、可维护性等多方面综合考虑。根据经验通常可以按照以下优先级顺序进行决策选择优先选择无锁方案如果业务场景允许优先使用原子类如AtomicInteger、LongAdder或volatile关键字。无锁方案没有任何线程阻塞和上下文切换开销能带来最高的并发吞吐量。适用场景低延迟的计数器、状态标志位、序号生成器等只涉及简单变量操作的场景。注意事项原子类仅适用于对单一变量的原子操作volatile仅能保证可见性和有序性二者都无法保证多步骤复合操作的原子性。其次选择synchronized关键字如果是简单的互斥同步场景并且不需要ReentrantLock的高级功能优先使用synchronized。它的语法更简洁不会引入额外的锁释放开销在 JDK 6 及以后JVM 对synchronized的锁优化非常彻底低竞争场景下的性能表现已经非常优异。适用场景方法级或代码块级的简单互斥同步、并发吞吐量要求不高的业务场景。注意事项不适合用在需要超时控制、可中断等待、以及极高并发的场景下。然后选择ReentrantLock显式锁如果synchronized无法满足需求比如需要获取超时控制、可中断等待、公平锁、或者多个 Condition 精准唤醒等高级功能优先使用ReentrantLock。它的锁机制更灵活在高竞争场景下的性能表现也比synchronized更稳定。适用场景高并发业务场景、需要精细化管理线程协作的场景、或者需要使用非公平锁提升吞吐量的场景。注意事项必须严格遵循try-finally范式释放锁确保即使临界区代码抛出异常锁也能被正常释放避免死锁。最后选择其他 JUC 并发工具如果上述方案都无法满足需求再根据具体的业务场景选择 JUC 包中的其他并发工具类。例如读多写少场景使用ReentrantReadWriteLock读写锁分离提升读操作并发度生产者 - 消费者场景使用BlockingQueue阻塞队列简化线程间的同步协作逻辑多线程任务协同场景使用CountDownLatch或CyclicBarrier实现线程间的批量同步等待流量控制场景使用Semaphore信号量限制同时访问特定资源的线程数量。5.2 锁优化实用建议不论使用哪种锁机制都可以通过以下的优化建议进一步降低锁的开销提升程序的并发吞吐量减少锁持有时间这是锁优化最核心的原则。在保证业务逻辑正确性的前提下应该尽量缩小锁的临界区范围只对涉及共享资源读写的核心代码进行加锁保护对于不涉及共享资源的业务逻辑完全可以移到临界区之外执行。这样可以有效减少其他线程的阻塞等待时间提升整体并发度。降低锁粒度如果业务场景允许可以将一个独占锁拆分为多个并行的细粒度锁将锁的竞争范围降低到最小。例如在业务场景允许的前提下可以将全局的单一锁拆分为按业务分片的多个独立锁或者使用ConcurrentHashMap的分段锁思想将锁竞争控制在最小范围内提升并发性能。选择合适的锁公平性非公平锁是ReentrantLock的默认模式它能减少线程切换的开销提升整体吞吐量公平锁会按照线程请求锁的顺序分配锁保证所有线程有机会获取锁但会带来额外的线程切换开销吞吐量相对较低。在大多数业务场景下建议使用非公平锁只有在对响应时间有严格要求、或者业务场景不允许线程饿死的情况下才使用公平锁。避免无谓的锁操作如果业务逻辑允许应该尽量避免使用锁优先使用原子类或其他无锁方案。对于只读的共享资源可以使用不加锁的线程安全类或者使用不可变对象彻底避免锁竞争。此外还可以通过锁消除、锁粗化等 JVM 级别的优化手段减少加锁的实际开销。使用高级并发工具替代基础锁读多写少场景下优先使用ReentrantReadWriteLock读写锁分离提升读操作的并发度需要对并发任务进行流量控制时使用Semaphore信号量需要在线程间进行精准的阻塞唤醒协作时使用BlockingQueue阻塞队列。这些工具类的封装性更好性能也比手动加锁更优。5.3 实际项目最佳实践结合大量实际项目的生产经验在使用 Java 并发编程工具时应该严格遵循以下几条最佳实践原则避免引入隐蔽的并发故障优先使用无锁方案只要业务场景允许应该优先使用原子类或volatile关键字而不是锁。无锁编程的性能上限更高也不会带来死锁等锁相关的风险。尽量缩小锁范围能使用同步代码块的场景就不要使用同步方法锁的临界区代码能少写就少写只对真正需要保护的共享资源操作进行加锁避免不必要的性能开销。ReentrantLock必须在finally块中释放锁使用ReentrantLock时必须严格遵循try-finally的加锁解锁范式 —— 在try代码块之外获取锁在finally代码块中释放锁。这样可以保证即使临界区代码抛出业务异常锁也能被正常释放不会导致死锁。尽量避免使用stop()、suspend()等废弃的线程控制方法这些方法是 JDK 早期提供的现在已经被标记为废弃状态。使用它们可能会导致线程在持有锁的情况下被强制中断或者导致线程长时间挂起进而引发死锁或资源不一致等问题。应该使用interrupt()方法或Condition条件的精准唤醒机制来实现线程的协作控制。优先使用并发容器而非手动加锁的同步容器JUC 包中提供了大量线程安全的并发容器比如ConcurrentHashMap、CopyOnWriteArrayList、ConcurrentLinkedQueue等。这些并发容器的内部已经通过精心的锁优化或无锁机制保证了线程安全而且性能比Collections.synchronizedXXX包装的同步容器更优。应该优先使用这些并发容器替代手动加锁的同步容器。并发编程代码必须经过性能测试和压力测试所有的并发代码在开发完成后不仅要在功能层面验证正确性还要在性能测试和压力测试环境下模拟生产级别的并发流量验证在高并发场景下的性能表现和数据一致性。只有经过充分的压测验证才能避免在生产环境中出现隐蔽的并发安全问题。六、总结Java 提供了一套完整的、覆盖从基础到高阶的线程安全解决方案从基础的synchronized关键字和volatile轻量级同步机制到高阶的ReentrantLock显式锁、原子类和 JUC 并发工具包开发者可以根据实际业务场景的并发需求灵活选择最合适的技术方案。通过本文的详细分析我们可以得出以下几条核心结论作为并发编程的选型参考原则线程安全的核心三要素是原子性、可见性和有序性任何一个并发控制方案都必须至少保证这三个要素中的一个或多个才能真正实现线程安全。无锁方案的性能优于锁方案在业务场景允许的前提下应该优先使用原子类或volatile关键字等无锁方案这类方案没有线程阻塞和上下文切换开销能支撑更高的并发吞吐量。锁方案中synchronized和ReentrantLock各有所长在低竞争、简单同步场景下synchronized的性能表现更优代码也更简洁在高竞争、需要精细化并发控制的场景下ReentrantLock的灵活性和性能表现更优。JUC 包提供了高阶并发控制的完整解决方案对于复杂的业务场景JUC 包中的ReentrantLock显式锁、原子类、阻塞队列、同步工具类可以充分满足开发需求简化并发编程的开发难度。作为 Java 开发者在实际业务中进行并发编程时不能只停留在使用 API 的层面而要深刻理解不同同步方案的底层原理、适用场景和性能差异。只有这样才能在保证线程安全的前提下最大化地提升程序的并发性能写出高可靠、高性能、可维护的并发编程代码。参考资料Java 官方并发编程文档Java Concurrency Multi-threading GuideJUC 包源码分析java.util.concurrent API 源码文档《Java 并发编程实战》Brian Goetz 等著机械工业出版社《Java 高并发编程详解》汪文君著机械工业出版社JMH 并发性能基准测试官方样例OpenJDK JMH SamplesReentrantLock 官方 API 文档Class ReentrantLock原子类底层实现原理深度解析Java Atomic Variables and CAS