Redisson初始化连接失败多因配置或版本不匹配；分布式锁重复执行主因超时设置不当或异常未释放锁；RMapCache是带过期和事件通知的分布式Map，非本地缓存；其自动续期等能力依赖稳定连接与规范使用。
Redisson 客户端初始化时连接不上 Redis 怎么办
多数问题出在连接配置和依赖版本不匹配，不是代码写错。Redisson 默认用 redis://127.0.0.1:6379，但如果你 Redis 开了密码、改了端口、或用了 Sentinel/Cluster，Config 必须显式构造，不能靠默认。
- 用单机模式但 Redis 设了密码？必须调
config.useSingleServer().setAddress("redis://127.0.0.1:6379").setPassword("yourpass") - 连的是 Redis 7+？确认用的是 Redisson 3.23.0+，老版本不支持 RESP3 和新认证方式
- Spring Boot 项目里混用了
spring-boot-starter-data-redis和 Redisson？别共用同一个连接池，容易触发ERR unknown command 'client' setname—— 关掉 Spring 的自动配置，或用RedissonAutoConfiguration替代
用 Redisson 实现分布式锁为什么还出现重复执行
根本原因不是没加锁，而是锁没设对超时时间，或业务逻辑抛异常后没释放锁。Redisson 的 RLock 是可重入、带自动续期的，但前提是线程活着且心跳正常。
- 别用
lock.lock()不带超时 —— 万一业务卡住，锁永远不释放；改用lock.tryLock(3, 10, TimeUnit.SECONDS)，第一个参数是等待时间，第二个是持有时间 - 加锁后业务里发生未捕获异常？必须包在
try-finally里，finally中调lock.unlock()，否则锁泄漏 - 用
RSemaphore或RCountDownLatch做协同时，注意它们不继承锁的自动续期机制，超时就得自己重置
Redisson 的 RMapCache 和普通 HashMap 有什么实际区别
RMapCache 是带过期、带事件通知、跨 JVM 共享的 Map，不是本地缓存。它底层走 Redis 的 HASH + EXPIRE 模拟，所以每次 put 都是网络请求，别当本地变量用。
- 想存用户会话（session）？
RMapCache合适，支持put(key, value, 30, TimeUnit.MINUTES)精确控制 TTL - 频繁读写小数据（比如计数器）？改用
RAtomicLong或RBucket，RMapCache的序列化开销和网络延迟明显更高 - 监听 key 过期？得开启 Redis 的键空间通知：
notify-keyspace-events Ex，否则map.addListener(new EntryExpiredListener())不生效
Spring Boot 里怎么让 Redisson 自动管理事务中的锁
Redisson 本身不参与 Spring 的 @Transactional，它的锁生命周期和数据库事务无关。所谓“事务内加锁”，其实是应用层协调：先锁再操作 DB，或者用 RTransaction 手动包裹 Redis 操作（仅限单机模式）。
- 不要指望
@Transactional回滚时自动释放RLock—— 它完全独立，必须手动 unlock - 需要强一致性？用
Redisson.getMultiLock(lock1, lock2)做多把锁的原子获取，避免死锁，但注意这会增加获取延迟 - 异步任务（@Async）里用锁？确保线程上下文没丢，
RLock绑定的是当前线程，子线程拿不到父线程的锁状态
