【锁的本质】锁本身就是共享资源,那么锁如何保证线程安全?

锁本身作为共享资源却能保证线程安全,以及AtomicInteger等原子类的线程安全实现,其根本原因都依赖于硬件层面的原子操作指令内存屏障。下面分层解析其原理:


一、锁如何保证自身线程安全(以 ReentrantLock 为例)

1. 底层依赖:CAS (Compare-And-Swap)
// AQS 中的核心 CAS 操作(简化版)
protected final boolean compareAndSetState(int expect, int update) {
    // 调用 Unsafe 类的 CAS 原子操作
    return unsafe.compareAndSwapInt(this, stateOffset, expect, update);
}
  • 硬件支持:CPU 提供 LOCK CMPXCHG 等原子指令(x86 架构)
  • 操作原子性:比较-交换操作在一条指令内完成,不会被线程切换打断
2. 锁获取流程(非公平锁)
final void lock() {
    if (compareAndSetState(0, 1))  // 原子操作:尝试将 state 从 0 改为 1
        setExclusiveOwnerThread(Thread.currentThread());
    else
        acquire(1);
}

关键保障

  1. 多个线程同时执行 CAS 时,只有一个线程能成功修改 state
  2. 失败线程进入 CLH 队列等待(通过 CAS 保证入队操作的线程安全)
3. 操作系统级保障

当竞争激烈时(重量级锁):

// HotSpot 源码中的锁膨胀(linux 实现)
void ObjectSynchronizer::inflate(Thread* self, oop object) {
    ...
    // 创建 ObjectMonitor 对象
    ObjectMonitor* monitor = new ObjectMonitor();
    // 通过 CAS 将对象头指向 monitor
    if (Atomic::cmpxchg_ptr(monitor, object->mark_addr(), mark) == mark) {
        ...
    }
}
  • 最终依赖操作系统提供的 mutex 互斥量(如 Linux 的 pthread_mutex_t
  • 通过系统调用(如 futex)实现线程阻塞/唤醒

二、AtomicInteger 的线程安全原理

1. 核心实现(JDK 源码)
public class AtomicInteger {
    private volatile int value;
    
    public final int incrementAndGet() {
        return unsafe.getAndAddInt(this, valueOffset, 1) + 1;
    }
}

// Unsafe 类中的关键操作
public final int getAndAddInt(Object o, long offset, int delta) {
    int v;
    do {
        v = getIntVolatile(o, offset); // 读取当前值
    } while (!compareAndSwapInt(o, offset, v, v + delta)); // CAS 重试
    return v;
}
2. 关键保障机制
机制作用实现层级
volatile 变量保证内存可见性(禁止指令重排序)JVM 内存屏障
CAS 操作保证修改的原子性CPU 硬件指令
自旋重试处理竞争失败Java 代码层

三、对比 Integer 的线程不安全

1. Integer 的自增操作
Integer count = 0;
count = count + 1; // 非原子操作

实际执行步骤:

  1. 读取当前值 count (非原子)
  2. 计算 count+1 (非原子)
  3. 写入新值 (非原子)
2. 多线程下的问题
// 线程 A          |  // 线程 B
read count=0       |
                   | read count=0
calc 0+1=1         |
                   | calc 0+1=1
write count=1      |
                   | write count=1  // 结果应为2,实际为1

四、根本原因对比

特性锁 (ReentrantLock)原子类 (AtomicInteger)Integer
原子性保障CAS+队列管理CAS 循环
可见性保障AQS 的 volatile statevolatile 变量
竞争处理队列阻塞CPU 自旋-
硬件依赖CPU 原子指令+OS 系统调用CPU 原子指令
适用场景复杂同步逻辑单一变量原子操作只读/线程局部变量

五、硬件与操作系统协作示意图

+---------------------+     +---------------------+
|     Java 代码层      |     |       JVM 层         |
|   - ReentrantLock   |<--->| - AQS 实现          |
|   - AtomicInteger   |     | - 锁膨胀机制         |
+----------↑----------+     +----------↑----------+
           |                           |
+----------↓----------+     +----------↓----------+
|  本地方法库 (JNI)   |     |     操作系统层        |
|   - Unsafe 类       |<--->| - mutex 互斥量        |
|   - CAS 操作        |     | - futex 快速锁        |
+----------↑----------+     +----------↑----------+
           |                           |
+----------↓----------+     +----------↓----------+
|        CPU 层       |     |       内存子系统      |
|  - LOCK 指令前缀    |<--->| - 缓存一致性协议      |
|  - CMPXCHG 指令     |     | - 内存屏障           |
+---------------------+     +---------------------+

六、关键结论

  1. 锁的自身安全根本原因

    • 硬件原子指令(CAS)保证状态修改的原子性
    • 内存屏障保证状态可见性
    • 操作系统提供阻塞/唤醒原语
  2. 原子类的线程安全根本原因

    • volatile 保证可见性
    • CAS 循环保证原子修改
    • 无锁设计避免上下文切换
  3. Integer 线程不安全原因

    • 复合操作(读-改-写)不具备原子性
    • 缺乏内存可见性保障

💡 设计启示

  • 简单原子操作优先使用原子类(如 AtomicInteger
  • 复杂同步逻辑使用锁(如 ReentrantLock
  • 避免在无同步下修改共享基本类型(如 int
原创作者: sun-10387834 转载于: https://www.cnblogs.com/sun-10387834/p/18976844
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值