RLock加锁会放大Redis压力，因大量请求并发争抢同一锁key触发高频EVAL脚本执行和自旋重试；需结合本地锁过滤、按业务实体分片锁粒度、禁用看门狗并显式设置租期。
直接用 RLock 加锁不能解决击穿性能瓶颈，反而可能让 Redis 更卡——关键不在“加不加锁”，而在“谁去加、什么时候加、加多细”。
为什么 tryLock() 在击穿场景下会放大 Redis 压力？
缓存击穿时，大量请求同时发现 redisTemplate.opsForValue().get(cacheKey) 返回 null，接着几乎全部调用 lock.tryLock(2, 5, TimeUnit.SECONDS)。这导致：
- 同一时刻成百上千个客户端争抢同一个锁 key（如
"lock:product:1001"），Redis 的 Lua 脚本执行队列被塞满 - 每次
tryLock都触发一次EVAL，含exists+hset+pexpire，CPU 和网络开销翻倍 - 没抢到锁的线程进入自旋重试（默认每 100ms 重试一次），在 5 秒超时窗口内可能发起 50+ 次无效请求
必须配合本地锁做第一道过滤
跨 JVM 的分布式锁不是万能药，同进程内的并发请求根本没必要打到 Redis。
- 用
ConcurrentHashMap构建本地锁容器，key 为业务维度（如"local_lock_product_" + productId） - 先尝试获取本地锁：
localLock.tryLock(50, TimeUnit.MILLISECONDS)；失败则直接返回或降级，不走 Redisson - 本地锁成功后，再调用
redisson.getLock("dist_lock_product_" + productId).tryLock() - 本地锁必须设超时，否则线程池可能被长期阻塞
锁粒度要按业务实体分片，不能全局一把锁
所有商品共用一个锁 key（如 "lock:product"）是典型反模式，会把压力全压到一个 Redis slot 上。
- 正确做法：锁 key 绑定具体资源，例如
"lock:product:" + skuId - 对超高频商品（如秒杀 iPhone），进一步哈希分片：
"lock:product_shard:" + (skuId.hashCode() & 0xF)，分散到最多 16 个 key - 分片数别超过 64，否则客户端内存和连接数会明显上涨
- 避免用字符串拼接时间戳或随机数作锁 key，会导致无法复用缓存与锁
禁用看门狗，显式设置 leaseTime
击穿场景中业务逻辑极短（查 DB + 写缓存通常 EVAL 续期。
- 一律使用
lock.lock(3, TimeUnit.SECONDS)或tryLock(1, 3, TimeUnit.SECONDS)，显式控制锁生命周期 - leaseTime 必须大于数据库查询 + 缓存写入的最大耗时，但不宜过长（建议 ≤ 5s），防止异常时锁残留
- 不传参的
lock()会启动看门狗，在 10 万 QPS 场景下等于每秒多出上万次无意义 Lua 调用
真正难的不是写出加锁代码，而是判断哪些请求根本不该走到锁逻辑里——本地锁漏掉的、分片后仍热点的、leaseTime 设短了导致提前释放的，这些边界情况比锁本身更容易引发线上事故。
