Java减少锁竞争提升性能技巧解析

学习文章要努力，但是不要急！今天的这篇文章《Java如何减少锁竞争提升性能解析》将会介绍到等等知识点，如果你想深入学习文章，可以关注我！我会持续更新相关文章的，希望对大家都能有所帮助！

应优先用无锁数据结构替代加锁，如ConcurrentHashMap、LongAdder、AtomicInteger等；细粒度控制需按业务拆分锁或哈希分段；避免锁升级，确保锁对象私有、final、稳定；读多写少用读写锁，极简读场景可选StampedLock。

用 ReentrantLock 替代 synchronized 做细粒度控制

synchronized 简单但粗放，锁住整个方法或代码块，容易让不相关的线程互相阻塞。换成 ReentrantLock 后，你可以按业务逻辑拆分临界区，比如把“查库存”和“扣库存”拆成两个独立锁，或对不同商品 ID 使用不同锁实例。

常见错误是直接用一个全局 ReentrantLock 代替所有 synchronized，结果锁竞争一点没少。真正有效的做法是：

• 为高频并发资源（如缓存桶、分段 Map）创建多个 ReentrantLock 实例，用哈希取模分配
• 避免在 lock() 和 unlock() 之间做耗时操作（如远程调用、IO）
• 务必在 finally 块中调用 unlock()，否则可能永久死锁

优先用无锁数据结构替代加锁容器

不是所有共享状态都需要锁。JDK 提供的 ConcurrentHashMap、AtomicInteger、LongAdder 等，底层基于 CAS 和分段思想，在多数场景下比手动加锁快得多，且不易出错。

例如高并发计数场景，用 LongAdder 替代 synchronized + int，性能提升常达 5–10 倍；而 ConcurrentHashMap 的 computeIfAbsent 能安全完成“检查-创建-返回”三步，无需额外同步。

注意点：

• ConcurrentHashMap 的 size() 不是 O(1)，它要遍历所有 segment，高并发下慎用
• AtomicReference 在需要原子更新对象引用时比锁更轻量，但不适用于复合逻辑（如先读再条件写）
• 别为了“无锁”强行套用 Unsafe 或自旋锁，JVM 对 synchronized 的锁消除和偏向优化已很成熟

避免锁升级和 monitor 争抢：减少 synchronized 误用

JVM 对 synchronized 做了大量优化，但前提是锁对象稳定、竞争低。一旦出现锁膨胀（从偏向锁 → 轻量级锁 → 重量级锁），每次进入临界区都要触发 OS mutex，性能断崖下跌。

典型诱因包括：

• 用可变对象（如 new Object() 或临时字符串）作锁，导致无法启用偏向锁
• 在循环内反复 synchronized 同一对象，但每次只做微小操作，放大上下文切换开销
• 锁对象被多个无关模块共用（比如全系统都用 MyClass.class 当锁）

实操建议：

• 锁对象声明为 private final Object lock = new Object();，确保唯一性和不可变性
• 把多次小同步合并为一次大同步（但需权衡持有时间，防止阻塞太久）
• 用 JFR 或 jstack 观察线程堆栈里是否频繁出现 Object.wait() 或 Unsafe.park()，这是重量级锁已生效的信号

用读写锁分离读多写少场景

如果某个状态被大量读取、极少修改（如配置中心的本地副本、路由表），ReentrantReadWriteLock 能显著提升吞吐。读锁可重入、允许多个线程同时持有；写锁独占，且会阻塞新读锁获取。

但要注意：

• 写锁获取前，所有等待的读锁和写锁都会排队，写操作频繁时反而比普通锁更慢
• StampedLock 更轻量，支持乐观读（tryOptimisticRead），适合读远多于写的极简场景，但它不支持重入，且使用不当易出错
• 不要在读锁内调用可能升级为写锁的方法（如某些集合的 computeIfAbsent 内部会写），会导致死锁

锁竞争不是靠“换更高级的锁”解决的，而是靠识别真正共享的变量、缩小临界区、以及用合适语义的数据结构替代裸锁。很多所谓“性能瓶颈”，其实只是锁范围划错了。

好了，本文到此结束，带大家了解了《Java减少锁竞争提升性能技巧解析》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多文章知识！