在Java中如何减少锁竞争提升性能_Java并发优化实践解析_技术教程

应优先用 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+）。

不要用 volatile 代替原子类做计数——volatile 不保证复合操作（如 i++）的原子性
ConcurrentHashMap 的 size() 是弱一致性，如需精确值应改用 mappin gCount()
高并发下避免频繁调用 keySet() 或 values()，它们会触发内部结构遍历，可能引发短暂阻塞

锁分离：读写锁与StampedLock的实际取舍

ReentrantReadWriteLock 在读多写少场景下能显著提升吞吐，但它的写锁是独占的，且读锁升级为写锁会导致死锁（JVM 不支持锁升级）。而 StampedLock 支持乐观读，更适合对延迟敏感、写操作极少的场景（如配置中心、元数据缓存）。

注意：StampedLock 不是可重入锁，也不支持条件变量，且乐观读失败后必须降级为悲观读锁——这点常被忽略，导致逻辑遗漏重试分支。

读多写少且写操作不频繁 → 选 StampedLock，但必须检查 validate(stamp) 返回值
需要条件等待（Condition）或写操作较频繁 → 用 ReentrantReadWriteLock
别在 StampedLock 的乐观读区内修改共享状态，否则验证必然失败

避免锁竞争的底层思路：减少共享、拆分状态、用消息代替同步

最彻底的“减锁”不是换锁，而是让线程尽量不共享数据。比如用 ThreadLocal 缓存数据库连接、格式化器或上下文对象；用分片（sharding）把一个全局计数器拆成 N 个 AtomicLong，最后求和；或者把同步调用改成异步事件（如用 Disruptor 或 BlockingQueue 解耦生产者与消费者）。

典型陷阱是滥用 ThreadLocal 导致内存泄漏——在线程池场景中，必须显式调用 remove()，否则引用的 value 无法被 GC。