connectionTimeout应设为2000ms以内，maxConnections和maxIdle按峰值QPS的1.5–2倍配置，retryInterval保持默认1500或调至2000，leaseTime≥30000且禁用Watchdog自动续期，unlock()必须置于finally块中。
connectionTimeout 设太大会让连接池卡死在建连阶段
秒杀或批量任务触发时，大量线程同时调用 tryLock()，如果 connectionTimeout 还保持默认 10000ms，而 Redis 连接池已满（比如 maxIdle=64），新请求就会排队等空闲连接 —— 但更糟的是，它们会先卡在 TCP 建连上，持续 10 秒才失败。这期间线程不释放、连接不归还，直接拖垮整个连接池。
实操建议：
- 压测确认真实建连耗时，把
connectionTimeout调到3000以内（例如 2000） - 同步扩大连接池：把
maxConnections和maxIdle都设为业务峰值 QPS 的 1.5–2 倍（比如峰值 3000 QPS，池子至少配 4096） - 禁用
connectTimeout的重试逻辑（Redisson 默认会重试 3 次），改用业务层兜底降级，避免雪球效应
retryInterval 设太小会让 Redis QPS 翻倍暴涨
当多个线程竞争同一把锁（如订单号锁），tryLock(waitTime, leaseTime, unit) 内部会在超时前不断轮询。每轮重试都走一次 Redis 请求，如果 retryInterval 设成 500，5 秒内就能发 10 次请求；而默认 1500 只发 3–4 次。高并发下，这会让 Redis 的 QPS 暴增数倍，甚至打满带宽或触发慢日志。
实操建议：
- 不要调低
retryInterval，保持默认1500或略上调至2000 - 如果业务允许等待更久，优先延长
waitTime，而不是缩短重试间隔 - 对非核心资源锁（如缓存预热），改用
tryLock(0, ...)直接失败返回，彻底避开重试
没关 Watchdog 或 leaseTime 过短会导致心跳风暴
Redisson 的看门狗（Watchdog）默认每 10 秒续一次锁，前提是 leaseTime = -1（即启用自动续期）。但如果业务方法执行时间波动大，又没控制好 leaseTime 下限（比如设成 5000），看门狗可能刚续完，锁就快到期，接着又续 —— 多个线程同时触发 Lua 续期脚本，形成 Redis 端的“心跳风暴”。
实操建议：
- 生产环境一律显式设置
leaseTime≥ 30000（30 秒），给看门狗留出安全缓冲 - 确认业务最长执行时间，把
leaseTime设为该值的 2–3 倍（例如最长 8 秒，就设 30 秒） - 禁用 Watchdog 的唯一方式是传正数
leaseTime，不要依赖 -1 + 手动续期，那反而更不可控
RLock.unlock() 不写在 finally 里会吃掉整个连接池
业务代码抛异常、超时中断、甚至 JVM OOM，都会导致 unlock() 没执行。锁在 Redis 里一直挂着，后续所有 tryLock() 请求要么等它过期（浪费时间），要么因重试机制反复打 Redis —— 最终表现就是连接数缓慢爬升、TIME_WAIT 堆积、redisson_netty_threads 线程跑满。
实操建议：
-
lock.lock()后必须紧跟try { ... } finally { lock.unlock(); }，别信“我这段代码肯定不会出错” - 加一层保护：用 AOP 拦截所有带
@RedisLock注解的方法，在方法退出时强制检查并释放锁（需记录 threadId） - 监控
redisson_lock_expired和redisson_lock_release_failed这两个指标，它们一涨，基本就是 unlock 漏了
connectionTimeout、retryInterval、leaseTime 和 unlock() 调用时机这四点咬合在一起的结果。最容易被忽略的是：连接池扩容后没同步调小 connectionTimeout，或者以为设了 leaseTime 就不用管 Watchdog —— 其实 Watchdog 是否启动，只取决于你传的是 -1 还是正数。 
