深入理解Java中的synchronized 和 ReentrantLock 底层原理_Java

synchronized 和 reentrantlock 是 java 中最核心的两种锁实现，前者是 jvm 内置锁（隐式锁），后者是 juc 显式锁（基于 aqs 框架）。两者的实现底层依赖完全不同，但核心目标一致 —— 通过「互斥」保证并发安全，下面从 底层依赖、核心流程、关键机制 三个维度，深入拆解它们的实现原理：

一、synchronized的实现：jvm 层面的 “自动锁”

synchronized 是 java 语言原生支持的锁，无需手动释放，底层由 jvm 解释器 + 操作系统内核 协同实现，核心依赖 对象头（mark word） 和 监视器（monitor），并通过「锁升级」机制优化性能。

1. 核心依赖组件

（1）对象头（mark word）：锁状态的 “存储载体”

java 中所有对象都能作为锁，本质是因为对象在内存中的「对象头」包含了锁相关的状态信息。对象头由两部分组成：mark word（核心）和 klass pointer（指向类元数据）。

mark word 是一个动态结构（32 位 jvm 示例），会根据锁状态变化存储不同信息，核心字段包括：

锁状态	mark word 结构（32 位）	核心作用
无锁状态	哈希码（25 位） + 分代年龄（4 位） + 锁标志位（01）	存储对象哈希码、gc 分代信息，无锁标识
偏向锁	线程 id（23 位） + epoch（2 位） + 分代年龄（4 位） + 锁标志位（01）	记录持有锁的线程 id，实现 “无竞争时零开销”
轻量级锁	指向栈帧中 “锁记录” 的指针（30 位） + 锁标志位（00）	关联线程栈中的锁记录，实现自旋锁机制
重量级锁	指向 monitor 的指针（30 位） + 锁标志位（10）	关联操作系统级别的 monitor，实现阻塞同步

👉 关键：mark word 的「锁标志位」决定当前锁状态，jvm 通过修改 mark word 实现锁的切换。

（2）监视器（monitor）：重量级锁的 “核心同步工具”

monitor 是操作系统层面的「互斥同步原语」（也叫管程），是 synchronized 重量级锁的核心依赖。每个 java 对象在创建时，jvm 会为其关联一个 monitor（可理解为 “锁对象”），monitor 内部包含三个核心结构：

所有者（owner）：存储当前持有锁的线程（唯一，保证互斥）；
entrylist（阻塞队列）：存储等待获取锁的线程（竞争失败后进入阻塞状态）；
waitset（等待队列）：存储调用 wait() 方法后释放锁的线程（需被 notify() 唤醒）。

👉 本质：monitor 通过操作系统的「互斥量（mutex）」实现线程阻塞 / 唤醒，是重量级锁性能开销的主要来源。

2.synchronized的核心实现流程（锁升级）

synchronized 并非一开始就是重量级锁，jvm 会根据「竞争激烈程度」自动触发「锁升级」（无锁→偏向锁→轻量级锁→重量级锁），目的是在 “无竞争” 和 “激烈竞争” 场景下都能保证性能。

（1）无锁 → 偏向锁（单线程竞争）

触发条件：只有一个线程尝试获取锁。
实现流程：
1. 线程 t1 第一次进入同步块时，jvm 通过 cas 操作 修改对象的 mark word：将「线程 id」写入 mark word，锁标志位保持 01（偏向锁标识）；
2. 后续 t1 再次进入同步块时，只需判断 mark word 中的线程 id 是否为自己：
  - 是：直接进入（无需任何同步操作，零开销）；
  - 否：偏向锁失效，触发升级。
核心目的：优化 “单线程重复获取锁” 的场景（如单线程操作集合），避免无意义的同步开销。

（2）偏向锁 → 轻量级锁（低并发交替竞争）

触发条件：有第二个线程 t2 尝试获取同一把锁（t1 未释放）。
实现流程：
1. jvm 先暂停 t1，撤销偏向锁（将 mark word 恢复为无锁状态）；
2. t1 和 t2 各自在自己的「栈帧」中创建一个「锁记录（lock record）」，锁记录中存储对象 mark word 的副本（displaced mark word）；
3. 两个线程通过 cas 操作 竞争修改对象的 mark word：将 mark word 指向自己的锁记录；
  - 成功：获取轻量级锁，进入同步块；
  - 失败：说明竞争存在，进入自旋重试（循环尝试 cas，避免阻塞）。
核心目的：优化 “多线程交替执行” 的场景（无激烈竞争），通过自旋减少线程阻塞 / 唤醒的开销（用户态操作，比内核态高效）。

（3）轻量级锁 → 重量级锁（高并发激烈竞争）

触发条件：自旋次数超过阈值（jdk1.6 后为「自适应自旋」，根据前一次自旋成功率动态调整），或有更多线程参与竞争。
实现流程：
1. 自旋失败的线程放弃竞争，将锁升级为重量级锁（修改 mark word 指向 monitor）；
2. 线程进入 monitor 的 entrylist 队列，放弃 cpu 资源（进入 阻塞状态，由操作系统调度）；
3. 持有锁的线程释放锁时，通过操作系统唤醒 entrylist 中的一个线程，该线程再次尝试获取锁。
核心目的：应对 “高并发激烈竞争” 场景，通过阻塞机制避免 cpu 空转（自旋会消耗 cpu）。

3. 解锁与自动释放机制

synchronized 无需手动解锁，jvm 会在以下场景自动释放锁：

线程退出同步块（synchronized 代码块或方法）；
线程抛出异常时（jvm 会在异常处理中插入解锁指令）。

解锁的核心操作：

轻量级锁：通过 cas 将 mark word 恢复为「displaced mark word」（锁记录中的副本）；
重量级锁：将 monitor 的「owner」设为 null，唤醒 entrylist 中的线程。

4. 内存语义的实现

synchronized 除了互斥，还能保证可见性和有序性，底层通过 内存屏障（memory barrier） 实现：

进入同步块时：插入「load barrier」，清空工作内存，从主内存加载最新共享变量（保证可见性）；
退出同步块时：插入「store barrier」，将工作内存中的修改刷新到主内存（保证可见性）；
同步块内：禁止指令重排序（保证有序性）。

二、reentrantlock 的实现：juc 层面的 “手动锁”

reentrantlock 是 java.util.concurrent.locks 包下的显式锁，基于 aqs（abstractqueuedsynchronizer，抽象队列同步器） 实现，支持公平锁 / 非公平锁、可中断、条件锁等灵活特性，完全由 java 代码实现（无需 jvm 介入）。

1. 核心依赖组件：aqs（锁的 “骨架”）

aqs 是 juc 同步工具的基础（如 reentrantlock、semaphore、countdownlatch），其核心设计是「状态变量 + 同步队列」，所有锁的逻辑都围绕 aqs 扩展。

（1）aqs 的核心结构

状态变量（state）：volatile int state，存储锁的状态：
- state = 0：锁未被持有；
- state > 0：锁已被持有，值等于「重入次数」（支持可重入）；
同步队列（clh 队列）：双向链表，每个节点是 node 对象，存储等待锁的线程、等待状态（如 cancelled、waiting）等；
独占线程（exclusiveownerthread）：存储当前持有锁的线程（仅用于独占锁，reentrantlock 是独占锁）。

（2）aqs 的核心模板方法

aqs 定义了一套「模板方法」，子类（如 reentrantlock 的内部类 sync）只需实现以下抽象方法，即可完成锁的逻辑：

tryacquire(int arg)：尝试获取锁（arg 为获取锁的次数，重入时 arg=1）；
tryrelease(int arg)：尝试释放锁（arg 为释放锁的次数，重入时 arg=1）；
isheldexclusively()：判断当前线程是否持有锁（支持可重入）。

👉 本质：aqs 封装了 “队列管理”“线程阻塞 / 唤醒” 等通用逻辑，子类只需实现 “锁的获取 / 释放” 核心逻辑，遵循「模板方法设计模式」。

2. reentrantlock 的内部结构

reentrantlock 本身不直接实现 aqs，而是通过内部类 sync 继承 aqs，再由 sync 的两个子类实现「公平锁」和「非公平锁」：

public class reentrantlock implements lock {
    // 核心同步器（继承 aqs）
    private final sync sync;
    // 抽象内部类：继承 aqs，定义锁的基础逻辑
    abstract static class sync extends abstractqueuedsynchronizer {
        abstract void lock(); // 抽象方法，由公平/非公平锁实现
        // ... 实现 tryrelease 等通用方法
    }
    // 非公平锁实现（默认）
    static final class nonfairsync extends sync {
        @override void lock() { /* 非公平锁加锁逻辑 */ }
        @override protected boolean tryacquire(int arg) { /* 非公平尝试获取锁 */ }
    }
    // 公平锁实现
    static final class fairsync extends sync {
        @override void lock() { /* 公平锁加锁逻辑 */ }
        @override protected boolean tryacquire(int arg) { /* 公平尝试获取锁 */ }
    }
    // 构造器：默认非公平锁
    public reentrantlock() { sync = new nonfairsync(); }
    // 构造器：指定公平/非公平
    public reentrantlock(boolean fair) { sync = fair ? new fairsync() : new nonfairsync(); }
}

3. reentrantlock 的核心实现流程（以非公平锁为例）

（1）加锁流程（lock() 方法）

// nonfairsync 的 lock() 方法
@override
public void lock() {
    // 第一步：尝试 cas 抢锁（state 从 0 改为 1）
    if (compareandsetstate(0, 1)) {
        // 抢锁成功，设置当前线程为独占线程
        setexclusiveownerthread(thread.currentthread());
    } else {
        // 抢锁失败，调用 aqs 的 acquire() 模板方法
        acquire(1);
    }
}
// aqs 的 acquire() 模板方法（通用逻辑）
public final void acquire(int arg) {
    // 第二步：尝试获取锁（tryacquire 由 nonfairsync 实现）
    if (!tryacquire(arg) &&
        // 第三步：获取失败，将线程封装为 node 加入同步队列
        acquirequeued(addwaiter(node.exclusive), arg)) {
        // 第四步：如果需要，中断当前线程（支持可中断）
        selfinterrupt();
    }
}
// nonfairsync 的 tryacquire() 方法（核心抢锁逻辑）
@override
protected boolean tryacquire(int arg) {
    return nonfairtryacquire(arg);
}
// sync 的 nonfairtryacquire() 方法（非公平抢锁细节）
final boolean nonfairtryacquire(int acquires) {
    final thread current = thread.currentthread();
    int c = getstate(); // 获取当前锁状态
    // 情况 1：锁未被持有（state=0），再次尝试 cas 抢锁
    if (c == 0) {
        if (compareandsetstate(0, acquires)) {
            setexclusiveownerthread(current);
            return true;
        }
    }
    // 情况 2：锁已被当前线程持有（可重入），state 加 1
    else if (current == getexclusiveownerthread()) {
        int nextc = c + acquires;
        if (nextc < 0) throw new error("maximum lock count exceeded");
        setstate(nextc); // 无需 cas，当前线程已持有锁，线程安全
        return true;
    }
    // 情况 3：锁被其他线程持有，抢锁失败
    return false;
}

加锁核心步骤总结：

线程先尝试「cas 抢锁」（插队，非公平锁的核心）；
抢锁成功：设置 state=1，标记当前线程为独占线程；
抢锁失败：
- 若当前线程已持有锁（重入）：state += 1，直接成功；
- 若锁被其他线程持有：将线程封装为 node 加入 aqs 同步队列，调用 locksupport.park() 阻塞线程。

（2）解锁流程（unlock() 方法）

// reentrantlock 的 unlock() 方法
public void unlock() {
    // 调用 sync 的 release() 方法（aqs 模板方法）
    sync.release(1);
}
// aqs 的 release() 模板方法（通用逻辑）
public final boolean release(int arg) {
    // 第一步：尝试释放锁（tryrelease 由 sync 实现）
    if (tryrelease(arg)) {
        // 第二步：释放成功，唤醒同步队列中的头节点线程
        node h = head;
        if (h != null && h.waitstatus != 0) {
            unparksuccessor(h); // 唤醒后继节点（locksupport.unpark()）
        }
        return true;
    }
    return false;
}
// sync 的 tryrelease() 方法（核心释放逻辑）
@override
protected boolean tryrelease(int releases) {
    int c = getstate() - releases; // state 减 1（重入时多次减）
    // 只有持有锁的线程能释放（否则抛异常）
    if (thread.currentthread() != getexclusiveownerthread()) {
        throw new illegalmonitorstateexception();
    }
    boolean free = false;
    // 情况 1：state 减为 0，完全释放锁
    if (c == 0) {
        free = true;
        setexclusiveownerthread(null); // 清空独占线程
    }
    // 情况 2：state > 0（重入未完全释放），仅更新 state
    setstate(c);
    return free;
}

解锁核心步骤总结：

线程调用 unlock()，state 减 1；
若 state == 0：完全释放锁，清空独占线程，唤醒 aqs 同步队列中的后继线程；
若 state > 0：仅更新 state（重入锁未完全释放）。

4. 公平锁与非公平锁的实现差异

核心差异在 tryacquire() 方法中，公平锁会多一步「判断队列是否有等待线程」：

// 公平锁 fairsync 的 tryacquire() 方法
@override
protected boolean tryacquire(int arg) {
    final thread current = thread.currentthread();
    int c = getstate();
    if (c == 0) {
        // 关键差异：先判断同步队列是否有前驱线程（hasqueuedpredecessors()）
        if (!hasqueuedpredecessors() && compareandsetstate(0, arg)) {
            setexclusiveownerthread(current);
            return true;
        }
    }
    else if (current == getexclusiveownerthread()) {
        // 重入逻辑与非公平锁一致
        int nextc = c + arg;
        if (nextc < 0) throw new error("maximum lock count exceeded");
        setstate(nextc);
        return true;
    }
    return false;
}
// aqs 的 hasqueuedpredecessors() 方法：判断队列是否有等待线程（先到先得）
public final boolean hasqueuedpredecessors() {
    node t = tail;
    node h = head;
    node s;
    // 队列不为空，且当前线程不是队列的第一个等待线程 → 有前驱线程
    return h != t && ((s = h.next) == null || s.thread != thread.currentthread());
}

非公平锁：抢锁时直接 cas，不关心队列是否有等待线程（允许插队，性能高，但可能导致饥饿）；
公平锁：抢锁前先检查队列是否有前驱线程，只有队列空或当前线程是第一个时才 cas（先到先得，无饥饿，但队列操作有性能开销）。

5. 可中断与条件锁的实现

（1）可中断锁（lockinterruptibly()）

reentrantlock 支持线程在等待锁时被中断，底层通过 aqs 的 acquireinterruptibly() 实现：

线程在同步队列中阻塞时，若收到中断信号（thread.interrupt()），会抛出 interruptedexception 并退出等待；
synchronized 不支持可中断（线程一旦进入阻塞，必须等到锁释放或程序终止）。

（2）条件锁（condition）

reentrantlock 可通过 newcondition() 获取 condition 对象，实现 “线程等待 / 唤醒” 的精细化控制（类似 object.wait()/notify()，但支持多个等待队列）：

condition 的底层是 aqs 的「等待队列」（每个 condition 对应一个独立等待队列）；
调用 condition.await()：线程释放锁，进入 condition 的等待队列，阻塞；
调用 condition.signal()：唤醒 condition 等待队列中的一个线程，使其加入 aqs 同步队列竞争锁。

三、synchronized与reentrantlock实现对比

维度	synchronized	reentrantlock
实现层面	jvm 内置（c++ 实现，如 hotspot 的 `synchronizer.cpp`）	java 代码层面（基于 aqs 框架，纯 java 实现）
核心依赖	对象头（mark word） + monitor（操作系统互斥量）	aqs（状态变量 + 同步队列） + cas + locksupport
锁升级	自动升级（无锁→偏向→轻量→重量）	无锁升级，始终是重量级锁（但通过 cas 减少阻塞）
释放机制	自动释放（退出同步块 / 抛异常）	手动释放（必须在 `finally` 中调用 `unlock()`）
公平性	仅支持非公平锁	支持公平 / 非公平（构造器指定）
可中断性	不支持	支持（`lockinterruptibly()`）
条件锁	不支持（仅 `object.wait()`/`notify()`，单等待队列）	支持（`condition`，多等待队列）
性能（jdk1.6+）	与 reentrantlock 接近（锁升级优化后）	高并发下略优（灵活控制队列和 cas）

总结

synchronized：jvm 原生支持，无需手动管理，通过「对象头 + monitor + 锁升级」实现，兼顾简单性和性能，适合大多数基础并发场景；
reentrantlock：基于 aqs 框架，通过「状态变量 + 同步队列 + cas」实现，支持公平锁、可中断、条件锁等灵活特性，适合复杂并发场景（如高并发读写、精细化线程控制）。

两者的核心都是「通过互斥保证原子性，通过内存屏障保证可见性和有序性」，但实现层面的差异导致了功能和性能的区别 —— 实际开发中，简单场景用 synchronized（不易出错），复杂场景用 reentrantlock（灵活可控）。

到此这篇关于深入理解java中的synchronized 和 reentrantlock 底层原理的文章就介绍到这了,更多相关java synchronized 和 reentrantlock内容请搜索代码网以前的文章或继续浏览下面的相关文章希望大家以后多多支持代码网！