通过“以空间换时间”的无锁方式，为每个线程提供独立的变量副本，从而优雅地解决了多线程环境下的数据隔离问题。它的诞生源于对复杂并发编程模型简化的需求，并由Josh Bloch和Doug Lea两位大师设计实现。特性大白话比喻底层原理核心思想每人一个私人储物柜每个线程持有，存自己的变量副本存储结构柜子上的格子Entry[]数组（开放地址法）Key 是什么柜子的编号（比如“柜子1号”）对象本身（弱引用）

角色作用提供互斥锁和可重入性提供等待/通知机制，让线程在条件不满足时释放锁并阻塞，条件满足时被唤醒调用流程核心await(): 释放锁 → 入条件队列 → 阻塞signal(): 出条件队列 → 入同步队列 → 等待锁 → 唤醒后重新竞争锁最终效果：线程既保证了临界区的互斥，又能高效地等待特定条件，避免无效循环和忙等。这正是Condition组合的强大之处。队列管理者存储内容节点转移方向AQS 同

AQS提供了一系列方法作为模板方法（例如acquire()release()），这些方法定义了获取或释放资源的整个操作流程，并且不允许子类覆盖，以保证线程调度逻辑的绝对安全。以独占式获取锁的模板方法if (!tryAcquire(arg) && // 1. 尝试获取锁，具体逻辑由子类实现acquireQueued(addWaiter(Node.EXCLUSIVE), arg) // 2. 获取失败

特性volatile原子性保证代码块内操作原子不保证（仅单次读写原子）可见性释放锁时刷新内存；获取锁时重载写后立即刷新；读前重新加载有序性锁内代码不会与锁外重排禁止特定重排序使用粒度方法或代码块（可多个变量）单个变量（字段）是否阻塞可能阻塞（重量级锁时）不阻塞，无上下文切换性能有锁升级优化，但竞争时仍较重非常轻量（仅加入内存屏障）适用场景复合操作、需要原子性状态标志、一次性安全发布（如 DCL）

特性finalvolatile主要目的安全发布对象（保证构造后字段可见）跨线程可见性及禁止重排序适用场景不可变对象、只读配置状态标志、轻量级同步内存屏障构造函数返回前插入 StoreStorevolatile 写前后插入多种屏障对复合操作不涉及不保证原子性重排序限制禁止 final 写与引用赋值的重排序限制更广，涉及读写。

概念抽象层面实现层面JMM 定义的可见性与顺序规则volatile 写规则对 volatile 写 happens-before 后续读StoreStore + StoreLoad 屏障volatile 读规则LoadLoad + LoadStore 屏障最终保证跨线程的可见性和禁止特定重排序具体 CPU 指令（x86: lock 前缀） + 缓存一致性协议（MESI）

StoreStore：保证屏障前的写先于屏障后的写，用于 volatile 写前。StoreLoad：最强屏障，保证写后读的可见性和顺序，用于 volatile 写后。另外还有LoadLoad和LoadStore，用于 volatile 读后。不同 CPU 架构对这些屏障的实际实现不同（x86 只有 StoreLoad 需要显式指令）。

ViewController客户端ViewController客户端fill:#333;important;important;fill:none;alt[存在异常]alt[preHandle返回true][preHandle返回false]发送请求checkMultipart (文件上传检查)getHandler (定位处理器)返回 HandlerExecutionChaingetHandler

大Key的定义并非绝对，它高度依赖你的业务场景、服务器性能和网络环境。数据类型一般场景（低并发）高并发场景典型参考规范String> 1 MB> 10 KB阿里云等规范建议控制在10KB内> 1万个元素> 5千个元素 或 总Value > 10MB建议集合元素个数不超过5000阿里云DAS诊断内存占用 >500 MB或 子元素 >2000个Redis大Key问题，治理的关键在于预防。在设计时，为K

最初没人抢 → 无锁。始终一个人进 → 偏向锁（记住你）。偶尔两个人抢 → 轻量级锁（原地等一会儿，不行就升级）。很多人抢 → 重量级锁（叫操作系统来排队）。这样设计是为了性能：绝大多数锁竞争并不激烈，用轻量级手段就够了。初始（无锁001）││ 第一个线程进入▼偏向锁（101）- thread ID││ 另一线程竞争▼轻量级锁（00） + 自旋││ 自旋超时 or 竞争加剧▼重量级锁（10） →