终极Java并发编程指南：synchronized与volatile底层原理及实战应用
项目地址: https://gitcode.com/gh_mirrors/ja/Java-Interview-Tutorial 在Java多线程开发中，synchronized和volatile是保证线程安全的两大核心关键字。本文将深入剖析这两个关键字的底层实现原理，结合实际应用场景，帮助开发者彻底理解并发编程的本质，轻松应对高并发场景下的线程安全问题。
一、synchronized：从重量级锁到智能锁升级
1.1 synchronized的锁状态演化
synchronized自JDK 1.6起经历了重大优化，引入了锁升级机制，从最初的重量级锁演变为包含无锁、偏向锁、轻量级锁和重量级锁四种状态的智能锁。这种设计使得synchronized在不同并发场景下都能保持高效性能。
图：Java对象头Mark Word在不同锁状态下的结构
锁状态转换流程：
- 无锁：对象创建初期的状态，Mark Word存储对象HashCode
- 偏向锁：单线程访问时，通过CAS将线程ID写入Mark Word
- 轻量级锁：多线程竞争时，升级为CAS自旋锁
- 重量级锁：自旋达到阈值后，升级为基于Monitor的阻塞锁
1.2 偏向锁：单线程优化的艺术
偏向锁是JVM针对单线程访问同步块的优化，它会"偏向"第一个获得锁的线程。当线程再次访问时，无需任何同步操作即可直接进入，极大提升了单线程场景下的性能。
public class BiasLockDemo {
private static Object lock = new Object();
public static void main(String[] args) {
// 首次加锁会触发偏向锁
synchronized (lock) {
System.out.println("偏向锁获取成功");
}
// 再次进入同步块无需竞争
synchronized (lock) {
System.out.println("偏向锁重入成功");
}
}
}
⚠️ 注意：JDK 15后偏向锁已被废弃，主要原因是高并发场景下偏向锁撤销的性能开销过大。
1.3 轻量级锁与自适应自旋
当有线程竞争时，偏向锁会升级为轻量级锁。轻量级锁通过CAS自旋获取锁，避免了线程阻塞的开销，适用于并发竞争不激烈且持锁时间短的场景。
JDK 1.6引入了自适应自旋优化：
- 若某锁自旋成功过，下次会允许更长时间的自旋
- 若某锁很少自旋成功，可能直接省略自旋过程
图：轻量级锁的获取流程示意图
1.4 重量级锁与Monitor机制
当CAS自旋达到一定次数或线程数超过CPU核心数时，轻量级锁会升级为重量级锁。重量级锁基于ObjectMonitor实现，通过操作系统的互斥量（Mutex）保证线程安全。
ObjectMonitor包含两个关键队列：
- EntryList：等待获取锁的线程队列
- WaitSet：调用wait()方法阻塞的线程队列
图：重量级锁的ObjectMonitor结构
1.5 synchronized的内存可见性保证
synchronized通过内存屏障保证可见性：
- 进入同步块时插入Load屏障，强制读取主内存最新值
- 退出同步块时插入Store屏障，强制刷新本地内存修改到主内存
int sharedVar = 0;
synchronized (this) { // monitorenter
// Load屏障：读取最新值
int local = sharedVar;
// 业务逻辑
sharedVar = local + 1;
// Store屏障：刷新修改
} // monitorexit
二、volatile：轻量级的线程可见性方案
2.1 volatile的核心作用
volatile是比synchronized更轻量级的同步机制，它主要提供两个保障：
- 可见性：一个线程对volatile变量的修改对其他线程立即可见
- 有序性：禁止指令重排序，保证代码执行顺序与预期一致
2.2 volatile的实现原理
volatile通过内存屏障实现可见性和有序性：
- 写操作：在volatile写指令前插入StoreStore屏障，后插入StoreLoad屏障
- 读操作：在volatile读指令后插入LoadLoad和LoadStore屏障
图：volatile变量读写时的内存屏障插入策略
2.3 volatile的使用场景
状态标志：作为多线程间的简单通信机制
public class VolatileFlagDemo {
private volatile boolean isRunning = true;
public void stop() {
isRunning = false;
}
public void run() {
while (isRunning) {
// 业务逻辑
}
}
}
双重检查锁定：实现单例模式的线程安全初始化
public class Singleton {
private static volatile Singleton instance;
private Singleton() {}
public static Singleton getInstance() {
if (instance == null) { // 第一次检查
synchronized (Singleton.class) {
if (instance == null) { // 第二次检查
instance = new Singleton(); // volatile防止指令重排序
}
}
}
return instance;
}
}
2.4 volatile的局限性
volatile不能保证原子性，以下代码在多线程环境下会出现问题：
// 错误示例：volatile不能保证原子性
private volatile int count = 0;
public void increment() {
count++; // 非原子操作，可能导致计数错误
}
解决方案：
- 使用synchronized加锁
- 使用AtomicInteger等原子类
private AtomicInteger count = new AtomicInteger(0);
public void increment() {
count.incrementAndGet(); // 原子操作
}
三、synchronized与volatile的对比与选择
3.1 功能对比
| 特性 | synchronized | volatile |
|---|---|---|
| 可见性 | ✅ 保证 | ✅ 保证 |
| 原子性 | ✅ 保证 | ❌ 不保证 |
| 有序性 | ✅ 保证 | ✅ 保证部分 |
| 性能开销 | 中高 | 低 |
| 适用场景 | 复杂同步逻辑 | 简单状态标记 |
3.2 性能对比
在不同并发场景下，两者性能表现不同：
- 单线程：volatile性能最优，synchronized偏向锁次之
- 低并发：synchronized轻量级锁性能接近volatile
- 高并发：synchronized重量级锁性能较差，建议使用并发容器
3.3 京东asyncTool框架的优化实践
在京东开源的asyncTool并行框架中，采用了CAS替代synchronized的优化方案：
"在asyncTool中并没有使用synchronized以及ReentrantLock这些比较重量级的锁，而是使用CAS来保证任务不会重复执行"
这种设计避免了synchronized可能导致的线程阻塞和上下文切换，显著提升了高并发场景下的性能。
四、并发编程最佳实践
4.1 锁优化策略
- 减少锁持有时间：只在必要代码段加锁
- 减小锁粒度：如ConcurrentHashMap的分段锁
- 锁粗化：合并连续的细粒度锁
- 避免锁竞争：使用无锁数据结构
4.2 常见并发陷阱
- 死锁：确保获取锁的顺序一致
- 活锁：引入随机等待时间
- 饥饿：使用公平锁或定时尝试机制
- 内存可见性问题：正确使用volatile或锁
4.3 并发工具推荐
- JUC原子类：AtomicInteger, AtomicReference等
- 并发容器：ConcurrentHashMap, CopyOnWriteArrayList
- 锁框架：ReentrantLock, ReadWriteLock
- 线程池：ThreadPoolExecutor
五、总结
synchronized和volatile作为Java并发编程的基础，各自有其适用场景：
- synchronized：功能全面，适合复杂同步逻辑，但性能开销较大
- volatile：轻量级，适合简单状态标记，不能保证原子性
在实际开发中，应根据具体场景选择合适的同步机制，必要时结合JUC包中的高级并发工具，才能构建高效且线程安全的系统。
通过深入理解这两个关键字的底层实现原理，开发者可以更好地把握Java并发编程的本质，编写出更健壮、更高效的多线程程序。建议结合docs/md/java/synchronized.md和docs/md/java/volatile.md文档进一步学习。
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
