reentrantreadwritelock通过分离读写锁提升读多写少场景吞吐量：读锁共享允许多线程并发读，写锁独占且精准阻塞新读请求；需避免耗时操作、锁泄漏和读锁升级等误用，非公平模式默认更优。
ReentrantReadWriteLock 通过把读和写操作的锁分开，让多个读线程能同时执行，而写操作保持独占，从而在读多写少场景下显著提升吞吐量。它不是“加了锁就快”，关键在于用对方式、避开常见坑。
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
读锁共享，实现真正并发读
普通锁（如 synchronized 或 ReentrantLock）不管读写，一律排队；而读写锁允许： - 多个线程同时获取 readLock()，只要没有线程持有 writeLock() - 100 个读请求可近乎并行进入临界区，不像互斥锁那样被串行化 - CPU 缓存行复用更高效，减少主存访问延迟 - 线程上下文切换大幅减少，调度开销下降
写锁独占，但阻塞范围精准可控
写操作本身不慢，慢的是获取时机。它的阻塞逻辑是： - 写线程必须等所有当前读锁释放后才能拿到写锁，确保数据状态一致 - 一旦写锁获取成功，后续新来的读请求会被挂起，但已进入读操作的线程不受影响 - 这种“只拦新读、不中断旧读”的设计，既保障一致性，又避免无谓中断
必须避开三类典型误用
错误用法反而比 synchronized 更慢： - 读锁内做耗时操作：比如远程调用、DB 查询、大对象拷贝，会拖长读锁持有时间，导致写线程长期饥饿 - 忘记在 finally 中 unlock()：锁泄漏会让后续所有线程卡死 - 尝试读锁升级为写锁：JVM 不支持，会永久阻塞；需先释放读锁，再单独获取写锁
非公平模式默认更优，多数场景无需调整
new ReentrantReadWriteLock() 默认是非公平模式： - 新来的读线程可能插队，略微延长写线程等待时间，但整体吞吐高 15%～30% - 公平模式唤醒逻辑重、上下文切换多，还无法缓解“大量读锁未释放”导致的写饥饿 - 除非监控发现写锁平均等待超 50ms，否则不建议开启公平模式
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
