redissonlock 必须通过 redissonclient.getlock() 获取，不可 new；锁 key 应带业务前缀且避免动态值；trylock 两时间参数需分离设置，等待时间 ≤ 业务耗时×0.7，过期时间 ≥ 业务耗时×1.5。
RedissonLock 初始化必须用 RLock 而不是直接 new
很多人卡在第一步：以为 RLock 是个普通类，试图 new RLock() 或手动实现接口。其实它只能通过 RedissonClient 获取——这是 Redisson 的核心设计：锁对象和连接生命周期强绑定，自己 new 会直接抛 NullPointerException 或 IllegalStateException。
正确做法是先配置好 RedissonClient 实例（单例！），再调用 getLock("my:lock:key")：
RedissonClient redisson = Redisson.create(config);
RLock lock = redisson.getLock("order:create:123");
- 务必复用同一个
RedissonClient实例，频繁创建会耗尽连接池、触发RedisConnectionPoolExhaustedException - 锁 key 建议带业务前缀（如
"order:create:" + orderId），避免不同服务误删对方锁 - 不要用时间戳、UUID 等动态值做锁 key 主体，否则无法重入或续期失效
tryLock(long, long, TimeUnit) 的三个参数到底怎么配
tryLock 是最常用也最容易配错的方法。第一个参数是「等待获取锁的最大时长」，第二个是「锁自动释放的过期时间」，第三个是单位。很多人把两个时间设成一样，结果锁还没用完就自动释放了，导致并发漏洞。
典型错误：lock.tryLock(10, 10, TimeUnit.SECONDS) —— 这等于说“我最多等 10 秒，拿到锁后只撑 10 秒”，但业务执行可能要 12 秒，锁提前释放，别人趁虚而入。
- 建议设置为：等待时间 ≤ 业务最大耗时 × 0.7，过期时间 ≥ 业务最大耗时 × 1.5（留出网络抖动和 GC 暂停余量）
- 如果业务耗时不确定，优先用
tryLock(long, TimeUnit)（只设等待时间），再配合lock.lockInterruptibly()+ 手动unlock() - 注意：过期时间太长（如设成 30 分钟）会导致故障时锁长期残留；太短（
没调用 unlock() 就 return 会导致锁永远不释放
Redisson 的锁默认开启看门狗（Watchdog）机制，只要线程还活着且没显式 unlock()，就会每 10 秒自动续期。但一旦方法里提前 return、抛异常没 catch、或者 JVM 直接 crash，unlock() 就永远不会执行——锁会一直挂着，直到过期时间到（如果设了的话）。
必须用 try-finally 包裹，哪怕你用了 Spring AOP 或注解式锁，底层也是靠这个保障：
RLock lock = redisson.getLock("key");
try {
if (lock.tryLock(3, 10, TimeUnit.SECONDS)) {
// 业务逻辑
return result;
}
} finally {
if (lock.isHeldByCurrentThread()) {
lock.unlock();
}
}
- 别依赖
lock.isLocked()判断是否该解锁——它返回的是锁是否存在，不是当前线程是否持有 - Spring @Transactional 事务回滚不会自动触发
unlock()，必须手动处理 - 异步线程（如
CompletableFuture）中获取的锁，不能在主线程unlock()，会报IllegalMonitorStateException
Redisson 配置不兼容 Redis Cluster 模式
本地开发用单节点 Redis 没问题，一上生产集群就报 org.redisson.client.RedisException: ERR Error running script 或锁行为异常——大概率是配置没切 Cluster 模式。
Redisson.create(config) 默认走单节点模式，Cluster 必须显式用 Config.useClusterServers()，且节点地址要写全：
Config config = new Config();
config.useClusterServers()
.addNodeAddress("redis://192.168.1.10:7001")
.addNodeAddress("redis://192.168.1.10:7002")
// ... 其他 master 节点，至少 3 个
RLock lock = redisson.getLock("key"); // 这时才真正走 cluster-aware 锁逻辑
- Cluster 模式下，锁 key 必须落在同一个 slot，Redisson 会自动加
{}哈希标签（如"{order}:create:123"），但你自己拼 key 时别漏掉 - 哨兵（Sentinel）模式要用
useSentinelServers()，和 Cluster 配置互斥，混用会启动失败 - 云 Redis（如阿里云 Tair、腾讯云 CRS）部分版本禁用 EVAL 命令，需确认是否支持 Lua 脚本——Redisson 锁底层全靠 Lua 实现原子性
Watchdog 续期、锁自动释放、跨节点一致性……这些都不是黑盒，而是由配置方式、key 设计、调用姿势共同决定的。稍有偏差，锁就从“保命符”变成“定时雷”。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
