Java读写锁需按业务实例粒度独立创建，每个资源（如UserCache）持专属ReentrantReadWriteLock，避免静态全局锁导致串行化；锁生命周期与资源一致，注意底层共享状态的分层同步，禁止池化锁。
Java 中读写锁本身不直接管理“多实例环境”，它只作用于单个 ReentrantReadWriteLock 实例所保护的共享资源。所谓“多实例环境”，通常指多个业务对象（如多个缓存容器、多个配置管理器、多个用户会话状态等）各自拥有独立的读写锁——这时资源管理的关键在于**锁与资源的绑定粒度**，而非锁本身的跨实例能力。
每个资源实例配一个独立读写锁
这是最常用也最安全的方式。每个业务对象（例如一个 UserCache 实例、一个 ConfigHolder 实例）内部持有一个专属的 ReentrantReadWriteLock：
- 读操作只锁定当前实例的读锁，不影响其他实例的并发读取
- 写操作仅阻塞对该实例的读/写，其他实例可照常运行
- 避免了全局锁导致的串行化瓶颈，天然支持水平扩展
锁粒度需匹配业务边界
不能简单地为整个服务或类定义一个静态读写锁，否则会变成“伪读写锁”——实际退化为串行访问。例如：
- ❌ 错误：用
static final ReadWriteLock GLOBAL_LOCK保护所有用户的缓存数据 → 所有用户读写互相阻塞 - ✅ 正确：每个
UserCache userCache = new UserCache(userId)持有自己的new ReentrantReadWriteLock()
锁的生命周期应与被保护资源一致：资源创建时初始化锁，资源销毁时无需显式释放（无 native 资源）。
立即学习“Java免费学习笔记（深入）”；
注意共享状态引发的隐式耦合
即使每个实例有独立锁，若多个实例间接依赖同一份底层共享状态（如共用一个 ConcurrentHashMap 存储、共用数据库连接池、共用静态计数器），仍可能产生竞争。此时需分层加锁：
- 上层：各实例用自己的读写锁控制自身逻辑一致性
- 下层：对真正共享的底层资源（如连接池、统计模块）单独加锁或使用线程安全类型
例如多个 CacheManager 实例都调用同一个 MetricRecorder.recordHit()，那这个 recorder 就需要自己的同步机制。
避免锁泄漏与误复用
在动态创建大量实例的场景（如按租户生成配置管理器），要防止锁对象被意外复用或泄漏：
- 不要将锁作为静态字段或从池中不当复用
- 确保每个新实例都新建锁，而不是从旧对象拷贝引用
- 若使用对象池，必须重置锁状态（但
ReentrantReadWriteLock不支持 reset，应避免池化锁本身）
锁是轻量级对象，新建开销极小，无需池化。
