高并发下应关闭偏向锁，优先用synchronized处理短临界区，分布式锁需带client ID和Lua校验，本地缓存TTL须短于锁过期时间。
偏向锁在高并发下不仅没用，还会拖慢性能
JVM 默认开启的 BiasedLocking 在单线程或低竞争场景下能省掉一次 CAS，但一旦出现真实多线程争抢，撤销偏向锁的代价远高于直接走轻量级锁。高并发服务里，你看到的 BiasedLockingRevocation 日志不是提示“可以优化”，而是明确信号：它正在成为瓶颈。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 线上高并发 Java 应用（如订单、支付、实时计算）务必关闭偏向锁：
-XX:-UseBiasedLocking - 确认是否生效：用
jstat -compiler <pid></pid>查看failed列是否归零；或加-XX:+PrintBiasedLockingStatistics看撤销次数 - 别信“升级 JDK 就自动修好”——JDK 15 起默认禁用，但 JDK 8u292 之前仍默认开启，老系统极易踩坑
synchronized 和 ReentrantLock 怎么选？看这三点就够了
不是“哪个更高级”，而是“谁更贴合当前锁的生命周期和调度需求”。synchronized 编译后是 monitorenter/monitorexit 指令，JVM 层面深度优化；ReentrantLock 是 API 层实现，靠 AQS + CAS，灵活性高但多一层调用开销。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 锁住代码块短（≤ 100 行）、无超时/中断/条件等待需求 → 无脑用
synchronized，JIT 编译后性能不输，且不会忘记unlock() - 需要
tryLock(100, TimeUnit.MILLISECONDS)或响应中断 → 必须用ReentrantLock，但记得包在try-finally里调用unlock() - 锁竞争激烈且持有时间长（如 IO 等待、复杂计算）→ 优先考虑缩小临界区，而不是换锁类型；换锁解决不了根本问题
Redis 分布式锁别直接用 SETNX，得防这三类失效
SETNX 只是原子写入，离“可用的分布式锁”差得远。生产环境常见问题不是“锁不上”，而是“锁住了却误释放”或“过期了但业务还没完”。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 必须带唯一 client ID（如 UUID）+ 设置过期时间：
SET lock:order:123 <client-id> EX 30 NX</client-id> - 释放锁必须用 Lua 脚本校验 client ID：
if redis.call("get", KEYS[1]) == ARGV[1] then return redis.call("del", KEYS[1]) else return 0 end - 业务执行时间不确定？别硬扛——拆成“预占锁 + 异步续期”（如 Redisson 的
watchdog），或改用租约模型（Lease-based）
本地缓存 + 分布式锁组合时，注意 key 失效的雪崩节奏
缓存穿透/击穿/雪崩不是理论概念，是本地 Caffeine 或 Guava Cache 配合 Redis 锁时，因 reload 时间差、TTL 不一致、锁粒度错配导致的真实故障。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 本地缓存 TTL 必须 严格短于 分布式锁的过期时间，否则锁已释放，本地还在返回旧值
- 避免对每个 DB 主键都建独立锁（如
lock:user:123），改用逻辑分组（如lock:user:shard-2），减少 Redis 压力 - 缓存 reload 失败时，别直接清空本地缓存——保留 stale 数据并设
refreshAfterWrite，比全量雪崩强得多
锁从来不是越“重”越安全，而是越贴近实际竞争路径越稳。很多人卡在“该用哪个锁”，其实真正要花时间的是画出那条临界路径：数据从哪来、谁会改、改多久、失败怎么兜底。路径没理清，换什么锁都是临时止血。
