Java synchronized机制与锁升级全解析-尧图网站建设

1. Java中的synchronized实现机制解析

在Java并发编程中，synchronized关键字是最基础的线程同步工具。它的核心实现依赖于JVM层面的Monitor机制和对象头数据结构。当我们在方法或代码块上使用synchronized时，编译器会在字节码层面生成对应的monitorenter和monitorexit指令。

1.1 Monitor的工作原理

每个Java对象都与一个Monitor相关联，这个Monitor由三部分组成：

Owner：记录当前持有锁的线程
EntryList：存放等待获取锁的线程
WaitSet：存放调用了wait()方法的线程

当线程执行到synchronized代码块时：

通过CAS操作尝试获取对象的Monitor
成功获取后会将Owner设置为当前线程
获取失败则进入EntryList等待

注意：Monitor的获取是排他的，同一时刻只有一个线程能成为Owner

1.2 对象头与锁标记

在HotSpot虚拟机中，对象头包含两部分重要信息：

Mark Word（32/64位）：存储对象的hashCode、GC分代年龄和锁状态标志
Klass Pointer：指向类元数据的指针

锁状态在Mark Word中的表示：

| 锁状态 | 存储内容 | 标志位 | |----------|-----------------------------------|--------| | 无锁 | hashCode+分代年龄 | 01 | | 偏向锁 | 线程ID+Epoch+分代年龄 | 01 | | 轻量级锁 | 指向栈中锁记录的指针 | 00 | | 重量级锁 | 指向互斥量（Monitor）的指针 | 10 | | GC标记 | 空 | 11 |

2. synchronized的锁升级过程

JDK1.6后对synchronized进行了优化，引入了锁升级机制：

2.1 偏向锁阶段

适用场景：没有实际竞争，且将来只有第一个申请锁的线程会使用锁

实现原理：

当线程第一次访问同步块时，通过CAS将线程ID写入Mark Word
后续该线程进入只需检查线程ID是否匹配
如果匹配则直接执行，不需要额外同步操作

实测数据：偏向锁的获取和释放比轻量级锁快约20%

2.2 轻量级锁阶段

触发条件：当有第二个线程尝试获取锁时，偏向锁升级为轻量级锁

加锁过程：

在当前线程栈帧中创建锁记录（Lock Record）
将对象头的Mark Word复制到锁记录中（Displaced Mark Word）
通过CAS将对象头Mark Word替换为指向锁记录的指针

解锁过程：

使用CAS将Displaced Mark Word替换回对象头
如果成功则解锁完成
如果失败表示存在竞争，升级为重量级锁

2.3 重量级锁阶段

触发条件：轻量级锁自旋超过阈值（默认10次）或有第三个线程竞争

特点：

通过操作系统的mutex实现
未获取锁的线程会被挂起
涉及用户态到内核态的切换，开销较大

锁升级流程图：

[无锁] → [偏向锁] → [轻量级锁] → [重量级锁]

3. 不同使用方式的底层差异

3.1 同步代码块

字节码表现：

public void syncBlock() { synchronized(this) { // code } }

对应字节码：

monitorenter // 代码逻辑 monitorexit

3.2 同步方法

实例方法：

public synchronized void syncMethod() { // code }

在方法flags中设置ACC_SYNCHRONIZED标志

静态方法：

public static synchronized void staticSyncMethod() { // code }

锁对象是类的Class对象

4. 性能优化实践

4.1 锁消除

JVM通过逃逸分析，发现同步代码不可能存在共享数据竞争时，会消除锁。例如：

public String concat(String s1, String s2) { StringBuffer sb = new StringBuffer(); sb.append(s1); sb.append(s2); return sb.toString(); }

StringBuffer是线程安全的，但在此方法中不可能被其他线程访问，JVM会去掉同步操作。

4.2 锁粗化

当检测到一连串操作都对同一个对象加锁时，JVM会将锁的范围扩大到整个操作序列。例如：

for(int i=0; i<100; i++) { synchronized(this) { // 操作 } }

可能被优化为：

synchronized(this) { for(int i=0; i<100; i++) { // 操作 } }

4.3 自旋优化

在轻量级锁阶段，线程会进行自旋等待（忙等待）。JVM采用适应性自旋策略：

根据前一次自旋是否成功动态调整自旋时间
自旋次数上限由-XX:PreBlockSpin参数控制（默认10）

5. 常见问题排查

5.1 死锁场景

典型死锁代码：

// 线程1 synchronized(objA) { synchronized(objB) { // ... } } // 线程2 synchronized(objB) { synchronized(objA) { // ... } }

排查方法：

jstack查看线程dump
查找"deadlock"关键词
分析互相等待的锁资源

5.2 锁竞争严重

表现症状：

大量线程处于BLOCKED状态
系统吞吐量下降
CPU使用率不高但响应变慢

解决方案：

减小锁粒度（拆分为多个锁）
使用读写锁（ReentrantReadWriteLock）
考虑无锁数据结构（如ConcurrentHashMap）

5.3 错误使用静态锁

错误示例：

private static final Object lock = new Object(); public void process() { synchronized(lock) { // 处理实例数据 } }

问题：所有实例共用同一个锁，导致不必要的串行化

正确做法：

private final Object lock = new Object(); public void process() { synchronized(lock) { // 处理实例数据 } }

6. 与ReentrantLock的对比

6.1 实现机制差异

特性	synchronized	ReentrantLock
实现层面	JVM原生实现	JDK代码实现（基于AQS）
锁获取方式	自动获取和释放	需要手动lock/unlock
中断响应	不支持	支持lockInterruptibly()
公平性	非公平	可配置公平/非公平
条件变量	只能有一个wait队列	可创建多个Condition

6.2 适用场景选择

推荐使用synchronized的情况：

简单的同步需求
需要自动释放锁的场景
对性能要求不苛刻的临界区

推荐使用ReentrantLock的情况：

需要可中断的锁获取
需要尝试获取锁（tryLock）
需要公平锁策略
需要多个条件变量

在实际项目中，我发现对于80%的同步需求，synchronized已经完全够用。只有在需要更灵活的锁控制时，才会考虑使用ReentrantLock。

资讯详情

Java synchronized机制与锁升级全解析