应优先用 ReentrantLock 替代 synchronized 实现细粒度锁控制，支持可中断、超时与公平策略；避免大锁，仅保护必要临界区，并配合 try-finally 确保 unlock；高并发场景优先选用无锁结构如 ConcurrentHashMap 和 AtomicInteger；读多写少时依需求选 StampedLock（乐观读）或 ReentrantReadWriteLock（需条件等待）；终极减锁策略是减少共享——通过 ThreadLocal、分片、异步化等手段规避竞争。
用 ReentrantLock 替代 synchronized 做细粒度控制
synchronized 是 JVM 层面的重量级锁，一旦进入同步块就锁住整个对象或类，容易造成线程排队。而 ReentrantLock 支持可中断、超时获取、公平/非公平策略，更重要的是——它允许你把锁范围缩小到真正需要保护的代码段。
常见错误是把整段业务逻辑包进一个大锁里，比如在缓存更新+DB写入场景中，只对 DB 操作加锁即可，缓存刷新可以异步或无锁完成。
- 用
lock.lock()/lock.unlock()显式控制边界，务必放在try-finally中，避免死锁 - 避免在锁内做 I/O、远程调用或长耗时计算；这些操作应移出临界区
- 非公平模式（默认）吞吐更高，公平模式仅在明确需等待顺序时启用
优先使用无锁数据结构：从 ConcurrentHashMap 到 AtomicInteger
多数共享计数、状态标记、高频读写的 Map 场景，根本不需要锁。JDK 提供的并发工具类已针对 CAS 和分段机制做了深度优化。
例如用 ConcurrentHashMap 替代 HashMap + synchronized，它的 computeIfAbsent 是原子的，且不会锁全表；AtomicInteger 的 incrementAndGet() 比加锁自增快 3–5 倍（实测 HotSpot 17+）。
立即学习“Java免费学习笔记（深入）”；
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 不要用
volatile代替原子类做计数——volatile不保证复合操作（如i++）的原子性 -
ConcurrentHashMap的size()是弱一致性，如需精确值应改用mappingCount() - 高并发下避免频繁调用
keySet()或values()，它们会触发内部结构遍历，可能引发短暂阻塞
锁分离：读写锁与StampedLock的实际取舍
ReentrantReadWriteLock 在读多写少场景下能显著提升吞吐，但它的写锁是独占的，且读锁升级为写锁会导致死锁（JVM 不支持锁升级）。而 StampedLock 支持乐观读，更适合对延迟敏感、写操作极少的场景（如配置中心、元数据缓存）。
注意：StampedLock 不是可重入锁，也不支持条件变量，且乐观读失败后必须降级为悲观读锁——这点常被忽略，导致逻辑遗漏重试分支。
- 读多写少且写操作不频繁 → 选
StampedLock，但必须检查validate(stamp)返回值 - 需要条件等待（
Condition）或写操作较频繁 → 用ReentrantReadWriteLock - 别在
StampedLock的乐观读区内修改共享状态，否则验证必然失败
避免锁竞争的底层思路：减少共享、拆分状态、用消息代替同步
最彻底的“减锁”不是换锁，而是让线程尽量不共享数据。比如用 ThreadLocal 缓存数据库连接、格式化器或上下文对象；用分片（sharding）把一个全局计数器拆成 N 个 AtomicLong，最后求和；或者把同步调用改成异步事件（如用 Disruptor 或 BlockingQueue 解耦生产者与消费者）。
典型陷阱是滥用 ThreadLocal 导致内存泄漏——在线程池场景中，必须显式调用 remove()，否则引用的 value 无法被 GC。
- Web 应用中，HTTP 请求生命周期内可用
ThreadLocal存放 traceId，但 filter 结束前要tl.remove() - 分片计数器的分片数不宜过多（一般 2–4 倍 CPU 核数），否则 cache line false sharing 反而拖慢性能
- 异步化后要注意错误传播和重试边界，不能因解耦丢失事务语义
锁竞争的本质是资源争抢，而资源争抢往往暴露的是设计问题：状态是否真需全局可见？操作是否必须强一致？很多所谓“高并发瓶颈”，其实只需要把“必须同步”的假设打掉一半，就能绕开大部分锁。
