synchronized不是乐观锁，也不是纯悲观锁，而是阻塞式悲观同步机制；它无冲突检测重试循环，不返回失败信号，直接阻塞线程，依赖JVM monitor与锁升级。
为什么 synchronized 不是乐观锁，也不是“纯悲观锁”
很多人以为 synchronized 就是典型的悲观锁实现，其实不准确。它底层用的是 JVM 的 monitor 机制，既有锁升级（偏向锁 → 轻量级锁 → 重量级锁），也依赖操作系统互斥量，但**它不尝试“先操作再验证”**，也不返回失败信号——它直接阻塞线程。所以它更接近“阻塞式悲观同步”，不是数据库里那种显式加 SELECT ... FOR UPDATE 的悲观锁逻辑。
关键点在于：它没有“冲突检测后重试”的循环结构，也没有版本号或时间戳校验步骤。一旦进临界区，就默认有竞争，且不给调用方留“非阻塞处理”的余地。
-
synchronized是 JVM 层的重量级保障，适合临界区较长、竞争不频繁的场景 - 它无法像
AtomicInteger.compareAndSet()那样返回false让你决定重试还是降级 - 在高并发短操作场景下，反复进入/退出 monitor 可能比 CAS 自旋开销更大
Atomic 类的 CAS 是怎么“乐观”起来的
AtomicInteger、AtomicReference 这些类的核心是 CPU 级的 compareAndSet() 指令（如 x86 的 CMPXCHG）。它不抢锁，而是“读-改-写”三步合并为一条原子指令：只在当前值等于预期值时才更新，否则直接返回 false。
这就把“是否冲突”的判断权交给了业务代码——你可以选择重试、放弃、记录日志，甚至切到 synchronized 回退路径。
立即学习“Java免费学习笔记（深入）”；
- 典型模式：
while (!atomicRef.compareAndSet(expected, newValue)) { expected = atomicRef.get(); } - 注意
expected必须每次重新读取，否则可能无限循环（ABA 问题虽不总致命，但逻辑可能错） - CAS 在低竞争时性能远超锁；但高竞争下自旋会浪费 CPU，JVM 10+ 对
Thread.onSpinWait()有优化，可酌情插入
什么时候该用 synchronized，什么时候该用 Atomic 类
选型不看“高级感”，而看操作粒度和失败语义是否可控。
- 需要锁住多行逻辑、涉及多个变量协同更新（比如账户扣款 + 记录流水），用
synchronized更安全直观 - 只更新单个变量，且能接受“失败即重试”或“失败即跳过”，
Atomic类更轻量 -
synchronized支持条件等待（wait()/notify()），Atomic类完全不提供线程协作能力 - 如果临界区里要调用可能阻塞的 IO 或外部服务，绝不能用 CAS 自旋，否则 CPU 白跑——这是最容易踩的坑
ReentrantLock 和 StampedLock 在哪卡住“乐观/悲观”的边界
ReentrantLock 默认仍是悲观阻塞，但它提供了 tryLock()，让你能主动判断是否获取成功，这就带上了点乐观味儿；而 StampedLock 更进一步，把读操作拆成“乐观读”（tryOptimisticRead()）和“悲观读锁”，写操作仍用独占锁。
但要注意：StampedLock 的乐观读不阻塞写，所以必须用 validate() 校验戳是否有效——漏掉这一步，就读到了脏数据。
long stamp = lock.tryOptimisticRead(); int v = x; if (!lock.validate(stamp)) { /* 降级为悲观读 */ }-
StampedLock不支持重入，也不能和synchronized嵌套使用，否则可能死锁 - 它的 stamp 是 long 类型，但不是时间戳，而是内部状态标识，不可手动构造或猜测
真正难的不是记住哪个是乐观、哪个是悲观，而是想清楚：你的业务能否容忍“操作被丢弃”，以及“失败之后要不要重试、重试几次、超时怎么处理”。这些决策藏在 while 循环里、藏在 if 判断里，而不是锁类型本身。
