编辑
Hello大家好!👋 我是摘星✨,今天我们来深度拆解Java并发编程中最经典的「悲观锁」🔒设计。
在多线程环境下,当你的转账操作被重复提交💸、库存被超卖📉、计数器结果离奇错误❌时,背后往往是因为缺乏合理的锁控制。而悲观锁作为Java并发中最「简单粗暴」的解决方案,从JDK1.0时代的重量级锁⛓️,到如今JVM层级的锁升级优化⚡,其底层实现堪称一部高性能并发的发展史📜。
本文将带你穿透**synchronized
关键字**的表面语法,直击三大核心问题💡:
- **🤔 为什么悲观锁能保证线程安全?**(从Java对象头到Monitor的硬件级协作)
- **⚡ JDK1.6后
synchronized
如何实现性能飞跃?**(偏向锁/轻量级锁的取舍智慧) - **🚫 高并发场景下如何规避锁的性能陷阱?**(从字节码层面理解锁膨胀的条件)
📌 举个真实案例:某电商平台在秒杀活动中使用synchronized
导致TPS从8000📈暴跌到300📉,最终通过缩小锁粒度+锁分离优化提升15倍性能🚀——我们将在文中用代码还原这个优化过程。
下面我们直接切入正题,从操作系统与JVM的协作契约🤝开始讲起!
目录
4.9.1. ReentrantLock与synchronized的对比
4.5. 锁记录
锁记录(Lock Record)是jvm用来支持轻量级锁的数据结构,是线程私有的,用于记录锁的状态,锁拥有者的信息以及竞争情况等等.
- 指向拥有者的指针(Owner Pointer):记录当前拥有锁的线程ID。在加锁的过程中,将对象头部的指针指向锁记录,以便快速定位拥有锁的线程。
- 标记位(Displacement):记录了对象头部的偏移量,用于在解锁的过程中恢复对象头部的标记字段。
- 锁状态(Lock State):记录了当前线程锁的状态,包括偏向锁、轻量级锁、重量级锁等。
在竞争情况下,多个线程会通过锁记录进行协调,实现了对轻量级锁的竞争和重量化的升级。当多个线程竞争同一把锁时,会通过锁记录中的信息协调竞争关系,避免无谓的自旋和竞争。
4.6. 偏向锁
偏向锁:当没有没有锁竞争时可以用偏向锁来优化
偏向锁的加锁过程:
- 偏向锁加锁:当线程第一次访问的同步代码块时,jvm会将该对象的锁标记为偏向锁01,同时将对象头中的mark word指向线程ID
- 偏向锁检查:当线程再次访问同一个加锁对象的
synchronized(obj)
代码块时,会先检查该对象的锁标记是否为偏向锁,是偏向锁且线程ID与当前线程ID一致,则无需加锁,直接进入代码块
偏向锁撤销过程:
- 当其他线程访问这个同步代码块时,发现线程ID不一致,偏向锁就会被撤销,升级为轻量级锁
- 调用wait/notify方法是也会撤销偏向锁,因为wait/notify方法只有重量锁才有
4.7. 轻量级锁
轻量级锁:如果有多个线程使用synchronized对一个对象加锁,但是加锁的时间是错开的,不会发生竞争时,可以使用轻量级锁来优化.
static final Object obj = new Object(); public static void method1(){ synchronized(obj){ method2() } } public static void method2(){ synchronized(obj){ } }
轻量级锁的加锁过程:
- 检测偏向锁:线程进入同步代码块时,首先会尝试偏向锁,如果对象的对象头中的锁标识位是01(偏向锁),且当前线程是偏向锁的拥有者,则直接进入同步代码块执行,不需要加轻量级锁.如果对象没有偏向锁,则会进入下一步CAS操作尝试获取轻量级锁.
- CAS操作尝试获取轻量级锁:线程进入同步代码块时会尝试通过CAS操作将对象头的markword指向锁记录
- CAS成功:当前线程成功获取了轻量级锁,对象锁标识位更新为00(轻量级锁)
- CAS失败-竞争:说明有其他线程也在竞争该对象锁,那么当前线程会进行自旋,尝试在短时间内快速获取锁
- CAS失败-重入:说明当前线程执行了一次加锁过程,会添加一条锁记录
轻量级锁的解锁过程:
- CAS操作尝试释放轻量级锁:当持有轻量级锁的线程退出同步块时,会尝试通过CAS操作将对象头中的markword恢复
- CAS成功:当前线程成功释放了轻量级锁m对象锁标识位更新为01(无锁状态),同时重置锁记录
- CAS失败:说明有其他线程正在竞争锁,此时轻量级锁会膨胀为重量级锁
4.8. 锁膨胀
轻量级锁竞争:当前线程加轻量级锁的CAS操作失败时,说明发生了锁的竞争,这时当前线程会进行自旋获取锁.自旋是通过忙等待,在一个循环中不断获取锁
自旋锁膨胀为重量级锁:当自旋达到一定的阈值时,会导致锁膨胀,将轻量级锁膨胀为重量级锁
- 当前线程为加锁对象申请Monitor锁,将对象头中的markword指向Monitor地址,锁标识位改为10
- 当前线程进入EntryList中,处于阻塞状态
- 当持锁的线程退出同步代码块时,尝试用CAS操作将对象头中的markword恢复
- CAS成功:成功释放锁
- CAS失败:进入重量级锁的解锁过程,将Monitor的owner清空,并将EntryList中阻塞的线程唤醒来竞争锁
4.9. ReentrantLock
4.9.1. ReentrantLock与synchronized的对比
在Java多线程中,ReentrantLock是一个可重入锁,相比与synchronized有更多的灵活性
共同点:
可重入
:ReentrantLock和synchronized都是可重入锁,即对一个对象反复加锁
不同点:
锁等待可终止
:ReentrantLock允许一个线程在等待锁的过程中被其他线程打断,然后可以选择继续等待获取终止.synchronized获取锁的过程中是不可被打断的超时时间
:ReentrantLock允许设置获取锁的超时时间,超过时间之后可以放弃获取这个锁.synchronized不能设置超时时间公平锁选择
:ReentrantLock允许选择公平锁或者非公平锁.synchronized只有非公平锁
- 在公平锁模式下,等待时间最长的线程将优先获取锁的访问权限,按先入先得的方式,防止饥饿现象出现,但是会降低并发度
- 在非公平锁模式下,让等待中的线程竞争锁,具有随机性
多个条件变量
:ReentrantLock提供了Condition允许多个条件变量存在,也就是多个waitlist,可以让线程满足某个条件时等待,也可以让其他线程满足某个条件时唤醒.synchronized只有一个条件变量- synchronized是关键字级别,ReentrantLock是对象级别
4.9.2. API介绍
private Lock lock = new ReentrantLock()
lock.lock()
:获取锁,不可被打打断lock.unlock()
:释放锁lock.lockInterruptibly()
:可打断,获取锁:获取锁失败进入阻塞状态时,可以被其他线程的interrput方法打断lock.trylock()
:尝试获得锁,返回值是boolean,true获取锁成功,false获取锁失败lock.trylock(long n,TimeUnit.SECONDS)
:尝试获得锁,获取不到锁等待n单位时间,时间到了还没获取到锁就返回false,时间内获取到锁还是返回true,支持可打断new ReentrantLock(true)
:设置公平锁,默认为false
Condition condition = lock.newCondition()//Condition可以创建多个也就是支持多个条变量
condition.await()
:await使用前需要获取锁,调用后释放锁,进入condition条件变量中等待,被唤醒(打断)后继续竞争lock锁,竞争成功后继续执行condition.await(long timeout,TimeUnit unit)
:等待指定超时时间condition.signal()
:从condition中随机唤醒一个等待中的线程condition.signalAll()
:从condition中唤醒全部等待中的线程condition.awaitUninterruptibly()
:等待不可被打断
try { // 获取锁 : 不可被打断 lock.lock(); // 在这里执行需要同步的代码块 } finally { // 释放锁 reentrantLock.unlock(); }
🎯 悲观锁总结:从原理到实战的完整指南 🔒➡️⚡
🔍 核心要点回顾
- 悲观锁哲学 🛡️
- "宁可错杀,不可放过"的设计理念
- 适合写多读少场景(支付/库存系统💰)
- synchronized进化史 🧬
- JDK1.6前:重量级锁⛓️(微秒级延迟)
- JDK1.6后:锁升级路径(无锁→偏向锁→轻量级锁→重量级锁)
- 关键对比 ⚖️
特性 | synchronized | ReentrantLock |
条件变量 | 单个 | 多个 |
可中断 | ❌ | ✅ |
超时控制 | ❌ | ✅ |
公平锁 | ❌ | ✅ |
💡场景选择指南 🗺️
- 简单场景 → synchronized(自动管理)
- 复杂需求 → ReentrantLock(超时/公平锁)
- 性能监控工具 🔧
- 使用JOL查看对象头:
System.out.println(ClassLayout.parseInstance(obj).toPrintable())
- Arthas监控锁竞争:
monitor -c 5 com.example.MyClass methodName
🚀 进阶路线
- 下篇预告 📢
- 无锁编程:CAS原理揭秘
- Atomic类性能对比
- 思考挑战 💭
当QPS超过10万时:
- 偏向锁是否反而降低性能?
- 如何选择自旋次数阈值?
📚 扩展学习
- 推荐书籍
- 《Java并发编程实战》📖
- 《并发编程的艺术》🎨
- 实战项目
- 实现一个带性能统计的锁装饰器
- 对比不同锁在秒杀场景的表现
🌟 一句话总结
"悲观锁用性能换取安全,而真正的艺术在于找到那个平衡点⚖️"
(欢迎在评论区分享你的锁优化经验🗨️,点赞收藏下次不迷路⭐️)