一张图看懂 synchronized 锁升级和 AQS 排队
前几篇把各种锁的原理和对比讲了一遍，但是"原理是懂了，但脑袋里没画面"。
锁升级到底是怎么一步步变重的？AQS 那个队列到底怎么排队怎么唤醒的？光看文字确实容易晕。
所以这篇我试着用画面感来写，把整个过程变成你能在脑子里"看到"的场景。
synchronized 的锁升级：从认人到打架
synchronized 不会一上来就用最重的锁。它是看情况来的——竞争的人少就轻着用，抢的人多了才变重。这个过程叫锁升级。
网上很多人说是"打怪升级"，我觉得挺贴切。
第一阶段：无锁
最开始，没有人来抢这把锁。它就是个普通对象，对象头里的 Mark Word 存的是哈希码之类的东西。
这个阶段没什么好说的——没人抢当然最省事。
第二阶段：偏向锁（"认人"模式）
来了第一个线程，它要进入同步块了。
这时候 JVM 想：“就你一个人，那我把你的 ID 记在对象头上，下次你再来就不用检查了，直接进。”
这就是偏向锁。它的样子大概是：
门上贴了一个铭牌，写着第一个线程的名字。这个线程每次来，看一眼铭牌是自己的，推门就进。不需要任何多余的操作。
速度最快——因为没有同步开销。就是一个最普通的 if 判断，比一比就过去了。
但，如果第二个线程来了呢？
铭牌上写的不是自己的名字，它就只能等着？不，它会尝试把铭牌上的名字改成自己的。
这时候就有竞争了。偏向锁觉得不对劲，开始撤退。
第三阶段：轻量级锁（"自旋"模式）
第二个线程来抢锁，偏向锁就升级成了轻量级锁。
这个阶段我自己的理解是两个人抢一把旋转门的钥匙：
两个人都站在门口，手里拿了个令牌。谁都想去替换门上的锁标记——换成自己的。
没抢到的人也不去睡觉，就站在门口原地转圈，一秒钟问十次"好了没？好了没？"。这叫自旋。
里面的人一出来，外面转圈的人立刻抢上去。
自旋的好处是不用把线程挂起再唤醒——挂起和唤醒是要操作系统帮忙的，开销很大。坏处是如果里面的人一直不出来，外面的人一直在转，CPU 就被白白烧掉了。
所以轻量级锁只适合"代码执行特别快，竞争也轻微"的场景。比如就执行一个 count++，几纳秒就完事了，自旋一小会儿完全等得起。
第四阶段：重量级锁（"阻塞"模式）
如果不止两个人抢了，三个、四个、一堆人都来了，一圈人在那里自旋，CPU 要被烧冒烟了。
JVM 这时候说：“算了，别转了，升级吧。”
重量级锁上来之后，操作方式完全变了：
没抢到锁的人，直接被安排到等候室睡觉（线程阻塞，让出 CPU）。里面的人出来的时候，由操作系统（保安）去叫醒下一个人。
这一来一回，从用户态切到内核态再切回来，开销不小。
但没办法，线程太多了，自旋更亏。
锁升级的完整路径画出来就是这样（JDK 15 之后）：
[无锁] │ 第一个线程来了 ▼ [轻量级锁] ───────> 出现多个线程同时竞争 ──────> [重量级锁] 自旋模式 阻塞模式 CAS 抢锁 Mutex Lock比原来少了偏向锁那一环。
ReentrantLock 的 AQS 排队：把它想象成银行柜台
ReentrantLock 跟 synchronized 的工作方式完全不同。它不搞锁升级那一套，它的核心是AQS（AbstractQueuedSynchronizer）。
我第一次理解 AQS 的时候，是靠一个画面：
一个银行网点，只有一个柜台在办业务。
AQS 内部就维护了这么几个东西：
- state 变量：0 表示柜台空着，1 表示有人在办业务，大于 1 表示同一个人反复办了好几个业务（可重入）
- 等待队列（CLH 双向链表）：排队的人，一个接一个串起来
画成图就是：
柜台（正在办业务）：线程A 排队的人： 线程B ←→ 线程C ←→ 线程D非公平锁怎么工作的（默认模式）
默认情况下的 ReentrantLock 是非公平锁。非公平锁的意思是：
允许插队。
流程是这样的：
1. 插队
线程来了，不管队列里有没有人在排队，它先看一眼柜台——如果柜台空着（state == 0），它直接冲上去，把 state 改成 1，开始办业务。
线程E 冲进来 → 看到柜台空着 → 一屁股坐下开始办业务 排队中的 B、C、D：？？？这就是非公平锁。
2. 判断是不是自己
如果柜台已经有人在办业务，它再看一眼——柜台坐着的会不会是自己？
如果是自己，那 state 加 1（重入）。比如自己连着办了两次业务，state 就是 2。
3. 乖乖去排队
如果柜台是别人，或者它没抢过别人，那就只能排队了。它把自己打包成一个 Node，挂在队列末尾。
4. 睡觉
排上了之后，它发现前面还有人。这时候它调用LockSupport.park()把自己休眠了，让出 CPU。
等前面的人办完了，会来叫醒它。
公平锁的区别：不许插队
公平锁的区别只有一句话：
到了柜台前先回头看一眼——后面有没有人在排队。
如果有人排队，即使柜台空着，你也不能直接坐上去。你得乖乖去队尾站着。
这个检查在 AQS 里对应的方法是hasQueuedPredecessors()——队列里有没有排在我前面的人？
奶茶店的例子
我跟朋友聊这个的时候，用奶茶店的例子解释。对方一下就懂了：
假设你在奶茶店买奶茶，前面的人刚买完走人，柜台空了。
非公平锁：你刚好站在柜台前，不管后面有没有人在排队，你直接对店员说"给我来一杯柠檬茶"。如果店员理你了，你就买到了——后面排队的人只能看着。
公平锁：你走到柜台前，先回头看一眼。如果取号机那儿还有人在等，你即使站在空柜台前也不能买，必须去队尾重新排队等叫号。
在性能上，非公平锁通常比公平锁快——因为线程刚释放锁，下一个线程刚好上来抢，这个时间窗口里大概率抢得到，省了唤醒其他线程的开销。公平锁虽然公平，但吞吐量低一些。
解锁的流程
不管公平还是不公平，解锁是一样的：
- 先确认——是不是自己坐在柜台里？不是的话抛异常
- state 减 1——如果减完还不是 0，说明还有重入没退出（比如 state 从 2 减到 1），流程结束
- 如果 state 变成了 0——说明彻底空出来了。AQS 会找到队列里的第一个人（头节点的下一个），调用
LockSupport.unpark()把它唤醒 - 被唤醒的人醒过来，再试着去抢锁
两个锁的工作方式，一句话概括
- synchronized：升级制。人少就轻着来，人多了再变重——“看人下菜碟”。
- ReentrantLock：排队制。来了就抢，抢不到就排队等叫号——“银行柜台”。
这两种思路没有绝对的好和不好。它们只是选择了不同的策略来解决同一个问题：多个人抢同一个资源的时候，怎么保证不乱套。
而且从结果来看，不管是哪种锁，最后落到代码层面，你写的都是同一件事——把需要保护的那几行代码包起来，不让多个线程同时碰。