在 Java 并发编程中，线程安全与锁机制是保障多线程环境下数据一致性的核心技术。本文从线程安全的本质定义、实现策略及主流锁机制的原理与实践展开，结合 JVM 底层实现与 JUC 框架特性，构建系统化知识体系，确保内容深度与去重性。

线程安全核心概念与分类

线程安全本质定义

线程安全指多个线程访问共享资源时，无需额外同步措施仍能保证操作结果符合预期。其核心挑战源于以下三个特性的冲突：

原子性：操作不可分割（如i++实际包含读 - 改 - 写三步，非原子操作）

可见性：线程对共享变量的修改需及时被其他线程感知（受 JVM 内存模型影响）

有序性：指令重排序可能导致操作顺序与程序逻辑不一致（需 Happens-Before 规则保障）

线程安全分类（按保证程度）

分类

核心特征

典型示例

不可变对象

对象状态在构造后不可修改，天然线程安全（利用 final 关键字）

String、Integer、Guava 的ImmutableList

绝对线程安全

所有操作均无需同步，任意线程调用均正确（实现成本极高）

Vector（同步方法，但迭代器非线程安全）

相对线程安全

特定操作需同步，通过文档说明线程安全的调用方式（最常用）

HashMap（非线程安全） vs ConcurrentHashMap（分段锁实现）

线程兼容

对象本身非线程安全，但可通过外部同步机制保证安全（如Collections.synchronizedList(list)）

普通集合类配合synchronized使用

线程安全实现策略

避免共享状态：

使用局部变量（Thread Local Storage，如ThreadLocal）

设计无状态对象（如无成员变量的工具类）

控制访问路径：

悲观锁（Pessimistic Locking）：假设冲突高频，提前加锁（如synchronized、ReentrantLock）

乐观锁（Optimistic Locking）：假设冲突低频，通过 CAS（Compare-And-Swap）检测冲突

使用线程安全类：

JUC 框架中的ConcurrentHashMap（分段锁→CAS→红黑树）

原子类AtomicInteger（底层 Unsafe 类 CAS 操作）

锁机制深度解析：从底层到高层

悲观锁：阻塞式同步的基石

内置锁synchronized

JVM 底层实现：

通过monitorenter/monitorexit字节码指令实现，对应对象头中的 Mark Word 锁状态（锁升级过程）：

锁升级优化（JDK1.6+）：

偏向锁（Biased Locking）：无竞争时仅记录线程 ID，避免 CAS 开销（通过-XX:+UseBiasedLocking开启）

轻量级锁（Lightweight Locking）：竞争不激烈时通过自旋（-XX:PreBlockSpin控制次数）避免线程阻塞

重量级锁（Heavyweight Locking）：竞争激烈时升级为内核级互斥锁，线程进入BLOCKED状态

特性对比：

特性

synchronized（隐式锁）

ReentrantLock（显式锁）

加锁方式

自动释放（代码块结束）

需手动调用unlock()（建议用try-finally）

公平性

非公平（默认）

可通过构造参数fair设置公平锁

锁超时

不支持

支持tryLock(long time, TimeUnit unit)

条件变量

不支持

支持newCondition()实现精准通知

显式锁ReentrantLock

核心特性：

可重入性：允许同一线程多次获取同一锁（通过计数器实现，与synchronized一致）

公平锁 vs 非公平锁：

公平锁：严格按等待队列顺序加锁，减少线程饥饿（但降低吞吐量）

非公平锁：允许刚释放的锁被当前线程再次获取，提升性能（默认策略）

中断响应：通过lockInterruptibly()允许等待线程响应中断，避免永久阻塞

典型应用：

private final ReentrantLock lock = new ReentrantLock();

public void transferFund(Account from, Account to, double amount) {

lock.lock(); // 加锁

try {

from.debit(amount);

to.credit(amount);

} finally {

lock.unlock(); // 确保解锁

}

}

乐观锁：无阻塞同步的实现

CAS（Compare-And-Swap）原理

核心逻辑：CAS(V, A, B)，若变量 V 的当前值等于 A，则将其更新为 B，否则不操作

三大问题：

ABA 问题：变量从 A→B→A 时，CAS 误判为未修改（通过AtomicStampedReference添加版本号解决）

循环开销：竞争激烈时导致多次重试，CPU 利用率升高

只能保证单个变量原子性：需结合AtomicReference处理对象引用的原子操作

无锁数据结构

无锁队列（Lock-Free Queue）：通过 CAS 实现入队 / 出队操作，如ConcurrentLinkedQueue

无锁栈（Lock-Free Stack）：利用 CAS 保证栈顶指针的原子更新，适用于高并发无阻塞场景

分级锁策略：优化锁粒度

读写锁ReentrantReadWriteLock

适用场景：读多写少（如配置中心、缓存系统）

锁模式：

读锁（共享锁）：允许多个线程同时获取，提高读并发

写锁（排他锁）：仅允许单个线程获取，写操作时阻塞所有读 / 写线程

性能对比：

在 100 读 1 写场景下，ReentrantReadWriteLock吞吐量比synchronized提升 3-5 倍

分段锁（Striped Locking）

典型实现：ConcurrentHashMap（JDK1.7）的Segment数组，将数据分片加锁

演进：JDK1.8 后优化为 CAS+ synchronized，锁粒度从分段细化到节点，进一步减少竞争

细粒度锁 vs 粗粒度锁

策略

优点

缺点

适用场景

细粒度锁

减少锁竞争，提升并发

增加锁管理开销

高并发共享资源操作

粗粒度锁

实现简单，减少上下文切换

并发度低，容易成为瓶颈

低竞争或操作耗时短场景

锁的最佳实践与陷阱规避

锁选择三原则

优先使用内置锁：

synchronized经过多年优化（锁膨胀、偏向锁等），性能接近ReentrantLock

代码简洁，避免忘记解锁导致的死锁（如ReentrantLock需严格遵守try-finally）

合理选择公平性：

公平锁适用于响应时间敏感场景（如数据库连接池线程调度）

非公平锁适用于吞吐量优先场景（大多数业务场景）

结合数据隔离：

通过ThreadLocal避免共享变量（如数据库连接、用户上下文）

使用CopyOnWriteArrayList（写时复制）处理读多写少且允许短暂不一致的场景

死锁预防与诊断

死锁四大必要条件

互斥条件：资源被单个线程独占

请求与保持：线程持有资源时请求其他资源

不可剥夺：资源只能被持有者释放

循环等待：线程间形成资源等待环

预防策略

破坏循环等待：对资源加锁按固定顺序（如按对象哈希值排序）

// 按对象地址排序加锁，避免循环等待

void transfer(Account a, Account b) {

Account first = (a.hashCode() < b.hashCode()) ? a : b;

Account second = (a.hashCode() < b.hashCode()) ? b : a;

synchronized (first) {

synchronized (second) {

// 转账逻辑

}

}

}

设置锁超时：使用ReentrantLock的tryLock(100, TimeUnit.MILLISECONDS)避免永久等待

减少锁持有时间：将非必要操作移到锁外（如日志记录、远程调用）

诊断工具

jstack：查看线程堆栈，识别BLOCKED状态线程及等待的锁

VisualVM：可视化线程状态，定位死锁对应的Monitor对象

面试高频问题深度解析

基础概念类问题

Q：如何理解线程安全中的 “原子性” 与 “可见性”？

A：

原子性指操作不可分割（如AtomicInteger.incrementAndGet()），通过 CAS 或锁保证

可见性指修改后其他线程能及时感知，通过volatile、锁或 Happens-Before 规则实现

二者无必然联系：volatile保证可见性但不保证复合操作原子性，synchronized同时保证二者

Q：String为什么是线程安全的？

A：

String对象不可变（所有字段final，无修改方法）

对String的操作（如concat）返回新对象，不影响原有实例

本质是通过不可变性规避共享状态修改，属于线程安全的最高级别（不可变对象）

锁机制对比问题

Q：synchronized 与 ReentrantLock 的核心区别？

A：

维度

synchronized

ReentrantLock

实现方式

JVM 内置关键字，自动管理锁

JUC 框架类，手动控制加锁 / 解锁

公平性

非公平（默认）

支持公平 / 非公平模式（可配置）

条件变量

仅wait()/notify()

支持多条件变量（Condition）

锁超时

不支持

支持tryLock()带超时参数

性能

优化后接近（偏向锁 / 轻量级锁）

细粒度控制下略优

Q：CAS 的缺点及解决方案？

A：

ABA 问题：通过AtomicStampedReference（带版本号）或AtomicMarkableReference（带标记位）解决

循环开销：竞争激烈时增加 CPU 压力，可结合yield()或自适应自旋优化

适用场景有限：仅保证单个变量原子性，复杂场景需结合锁

实战调优类问题

Q：高并发下如何优化锁性能？

A：

减少锁粒度：如ConcurrentHashMap的分段锁设计，避免全表加锁

锁分离：读写锁ReentrantReadWriteLock分离读 / 写操作

锁粗化：合并多次连续的加锁 / 解锁（JVM 自动优化，如循环内锁移到外部）

无锁化改造：使用原子类或无锁数据结构（如AtomicLong替代synchronized计数器）

Q：如何诊断和解决线上死锁？

A：

定位死锁线程：通过jps获取进程 ID，jstack 查看线程堆栈，寻找BLOCKED且waiting for monitor entry的线程

分析资源依赖：检查线程等待的锁对象，确认是否形成循环等待

代码修复：

按固定顺序加锁，避免嵌套锁

使用带超时的tryLock，释放已持有资源

减少锁持有时间，避免阻塞在锁内的长时间操作

总结：构建线程安全知识体系的三层架构

理论层

理解线程安全的本质（共享状态下的三性保障），区分不同线程安全级别的设计思想（不可变性、锁机制、无锁算法）

掌握 Happens-Before 规则与锁机制的映射关系（如synchronized的解锁 - 加锁对应监视器锁规则）

实现层

深入 JVM 底层：synchronized的锁升级过程（偏向锁→轻量级锁→重量级锁），Mark Word 的锁状态存储

精通 JUC 框架：ReentrantLock的 AQS（AbstractQueuedSynchronizer）实现原理，读写锁的状态机设计

实践层

能根据场景选择最优同步策略：高并发读选ReentrantReadWriteLock，低竞争选synchronized，无阻塞场景用 CAS

掌握死锁预防的工程方法：锁顺序控制、超时机制、锁粒度优化，结合jstack等工具诊断线上问题

通过将理论原理与 JVM 底层实现、JUC 框架源码分析相结合，既能应对 “synchronized 如何实现可重入” 等细节问题，也能解决 “高并发接口性能瓶颈” 等综合场景，展现高级程序员对线程安全与锁机制的系统化掌握与工程实践能力。