ReentrantReadWriteLock 不能直接替代 synchronized，因其需手动调用 lock() 和 unlock()，遗漏 unlock() 会导致死锁或饥饿；读锁不可升级为写锁，否则易引发死锁；必须用 try-finally 确保解锁；公平模式降低吞吐但防写饥饿。

ReentrantReadWriteLock 为什么不能直接替代 synchronized

因为 ReentrantReadWriteLock 不是语法糖，它不自动管理锁的获取与释放，必须显式调用 lock() 和 unlock()；而 synchronized 是 JVM 层保障的自动加解锁。一旦忘记在 finally 块中调用 unlock()，就会导致写线程永久阻塞或读线程饥饿。

读锁和写锁的获取规则与典型误用

读锁可被多个线程同时持有，但写锁是独占的；更重要的是：写锁可以降级为读锁（通过先获取写锁再获取读锁），但读锁**不能升级为写锁**——这是常见死锁源头。

• 错误写法：readLock.lock(); writeLock.lock(); → 极大概率死锁，因为其他线程可能正持读锁，而写锁在等所有读锁释放
• 正确降级示例：

  writeLock.lock();
  try {
      // 修改数据
      data = newValue;
      // 再获取读锁（此时仍持有写锁，安全）
      readLock.lock();
      writeLock.unlock(); // 释放写锁，保留读锁
  } catch (Exception e) {
      writeLock.unlock();
      throw e;
  }

• 读锁不排斥读锁，但会阻塞写锁；写锁则排斥一切读/写锁

如何避免 lock() / unlock() 配对遗漏

最稳妥的方式是把加锁逻辑封装进工具方法，强制走 try-finally 路径。不要依赖 try-with-resources（ReentrantReadWriteLock.ReadLock 和 WriteLock 并未实现 AutoCloseable）。

java-api-doc-generator

分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。

下载

• 推荐模式：

  readLock.lock();
  try {
      return data; // 仅读操作
  } finally {
      readLock.unlock();
  }

• 写操作同理：

  writeLock.lock();
  try {
      data = computeNewValue();
  } finally {
      writeLock.unlock();
  }

• 注意：lockInterruptibly() 可响应中断，适合需要取消等待的场景；普通 lock() 会一直阻塞

公平性设置对性能和吞吐的影响

ReentrantReadWriteLock 默认是非公平的（构造函数传 false 或无参），意味着新来的读线程可能插队已等待的写线程，造成写饥饿。设为公平（true）能保证 FIFO，但显著降低吞吐量——尤其在高并发读场景下。

立即学习“Java免费学习笔记（深入）”；

• 非公平模式：适合读多写少、对写延迟不敏感的缓存类场景
• 公平模式：适合写操作有强时效要求（如配置热更新、状态同步），且写频次不低的情况
• 公平锁的代价不仅是调度开销，还在于每次 lock() 都需检查队列头，影响 CPU cache line 利用率

读写分离不是加个锁就完事；真正难的是判断哪里该用读锁、哪里必须用写锁，以及能否接受读锁期间数据被其他写线程修改——这取决于你的业务一致性模型。别只盯着锁对象，先想清楚“这个读操作容忍脏读吗”。