锁竞争激烈怎么优化解决？

本文目录导读：

1. 减少锁持有时间（最直接有效）
2. 降低锁粒度（分拆大锁）
3. 使用无锁或轻量级同步
4. 避免共享数据（无锁化）
5. 锁算法与数据结构优化
6. 调整 JVM 锁参数（JVM 层面）
7. 架构级方案（彻底避免锁）
8. 诊断工具（先找到瓶颈）
9. 总结决策树

锁竞争激烈是并发编程中常见的性能瓶颈,核心思路是：减少锁持有时间、降低锁粒度、避免不必要的锁。

以下是针对不同场景的优化策略,按推荐优先级排序：

减少锁持有时间（最直接有效）

原则：只锁关键代码段，不要在锁内做耗时操作。

• 错误示例：

  public synchronized void process(List<Item> items) {
      // 这里有一个耗时10秒的网络请求
      Item result = networkCall();
      // 更新共享变量
      cache.put(result.getId(), result);
  }

• 优化后：将网络请求移出锁外。

  public void process(List<Item> items) {
      Item result = networkCall(); // 耗时操作不加锁
      synchronized (this) {
          cache.put(result.getId(), result);
      }
  }

降低锁粒度（分拆大锁）

原则：将一把大锁拆成多把小锁，允许多个线程操作不同资源。

• 锁分段（Segment）：经典代表是 ConcurrentHashMap 1.7 版本（16个Segment），JDK 1.8 改用CAS+红黑树，锁粒度细化到每个桶。
• 读写分离：ReadWriteLock 或 StampedLock。
  • 读多写少场景：允许多个线程同时读，写线程独占。
  • 写操作很少时,读性能可以提升几十倍。
• 示例：一个银行账户系统，如果只有一把锁，所有转账互斥，如果按账户 ID 哈希分段，不同账户的转账可以并发。

使用无锁或轻量级同步

原则：用 CAS（Compare-And-Swap）代替悲观锁。

• AtomicInteger / AtomicLong：使用 CPU 硬件指令 CAS，适用于计数器、状态标识等简单操作。
• LongAdder：比 AtomicInteger 更适合高并发，它将热点数据分散到多个 Cell 中，更新时只加锁当前 Cell，读取时求和，适合写多读少的统计场景（如 QPS 计数）。
• 乐观锁：数据库层面的乐观锁（版本号/时间戳），解决跨进程锁竞争。

避免共享数据（无锁化）

原则：能不共享就不共享。

• ThreadLocal：每个线程持有一份变量副本，彻底消除竞争，适用于线程内上下文传递（如用户 Session、数据库连接）。
• 写时复制（CopyOnWrite）：CopyOnWriteArrayList / CopyOnWriteArraySet，读操作不加锁（直接读数组），写操作加锁并复制一份新数组。适合读远多于写的场景（如黑白名单、缓存配置）。
• 最终一致性：允许短暂不一致，通过异步合并（如本地内存+MQ）。

锁算法与数据结构优化

原则：改变获取锁的方式，或者换一种数据结构。

• 自旋锁：对于锁持有时间极短（微秒级）的情况，自旋等待比线程挂起/唤醒的上下文切换更优。
• CLH锁 / MCS锁：公平锁，按线程到达顺序排队，避免“锁饥饿”。
• 无锁队列：如 ConcurrentLinkedQueue（基于CAS链表，常用于高性能消息队列）。
• Disruptor 框架：使用 RingBuffer + 预分配 + 事件处理，完全无锁，每秒可处理数百万级交易。

调整 JVM 锁参数（JVM 层面）

原则：让 JVM 的偏向锁、轻量级锁发挥最佳效果。

• -XX：-UseBiasedLocking：关闭偏向锁，如果锁总是被多个线程竞争，偏向锁反而导致额外的撤销成本，高并发场景下常关闭它。
• -XX：+UseHeavyMonitors：强制使用重量级锁（系统互斥量），某些场景下（如锁持有时间较长），直接使用操作系统锁可能更稳定。

架构级方案（彻底避免锁）

原则：从系统设计上消除资源争夺。

• 分库分表：将热点数据分散到不同数据库实例（Sharding）。
• 分布式锁优化：避免用 Redis 分布式锁做高频操作，可以用本地锁 + Redis 兜底（先锁本地，再尝试获取分布式锁），或者用ZooKeeper 的顺序节点实现公平锁。
• 异步化：将写操作先放入队列，由单线程消费者顺序处理，用等待队列的 FCFS 替代并发锁。

诊断工具（先找到瓶颈）

不要盲目优化,先定位到底哪里锁竞争激烈：

1. 分析工具：
   • jstack：抓线程快照，看哪些线程在 BLOCKED 状态。
   • jvisualvm / async-profiler：观察锁的 overhead。
   • JFR（Java Flight Recorder）：记录锁竞争事件。
2. JVM 参数：
   • -XX：+PrintConcurrentLocks（JDK 11+）：打印锁信息。
   • -XX：+UnlockDiagnosticVMOptions -XX：+PrintBiasedLockingStatistics：打印偏向锁统计。

总结决策树

核心建议：先写正确的代码，通过分析工具找到真正的热点锁，再针对性地应用上述策略。过度优化（比如把短锁改成CAS导致ABA问题）反而会引入 bug。

标签： 优化方案