Java并发锁优化技巧详解

知识点掌握了，还需要不断练习才能熟练运用。下面golang学习网给大家带来一个文章开发实战，手把手教大家学习《Java并发锁竞争优化技巧分享》，在实现功能的过程中也带大家重新温习相关知识点，温故而知新，回头看看说不定又有不一样的感悟！

应优先用无锁结构（如ConcurrentHashMap、AtomicInteger）替代显式锁；必须加锁时，用ReentrantLock细粒度控制，只锁共享状态修改部分，并配合tryLock()、ThreadLocal等降低竞争。

用 ReentrantLock 替代 synchronized 做细粒度控制

synchronized 简单但粗放，锁住整个方法或代码块，容易把不相关的操作也串行化。而 ReentrantLock 支持可中断、超时获取、公平性选择，更重要的是能配合 tryLock() 实现非阻塞尝试，避免线程长时间挂起。

常见错误是直接用 lock() 包裹大段逻辑，结果锁持有时间过长；正确做法是只锁真正共享状态修改的部分，比如：

private final ReentrantLock lock = new ReentrantLock();
private int counter = 0;

public void increment() {
    // 只锁计数器更新这一行
    lock.lock();
    try {
        counter++;
    } finally {
        lock.unlock();
    }
}

• 别在 lock() 前做 I/O、远程调用或耗时计算
• 必须用 try-finally 保证 unlock() 执行，否则会永久死锁
• 高竞争场景下考虑 lock.tryLock(1, TimeUnit.MILLISECONDS) 配合退避重试

优先用无锁数据结构：从 ConcurrentHashMap 到 AtomicInteger

很多场景根本不需要显式加锁——只要操作是原子的、无依赖的，就该交给 JVM 底层的 CAS 指令处理。比如计数、状态标记、缓存读写。

ConcurrentHashMap 默认分段（Java 8+ 是基于 Node 数组 + TreeBin 的细粒度锁），比 Hashtable 或 synchronized(new HashMap()) 并发吞吐高得多；AtomicInteger 的 incrementAndGet() 比加锁自增快 3–5 倍。

• 避免把 ConcurrentHashMap 当普通 Map 用：containsKey() + put() 不是原子的，要用 computeIfAbsent()
• AtomicReference 适合封装简单对象状态，但注意它不保证内部字段的可见性，别用来包装含多字段的可变对象
• 不要为了“看起来线程安全”而滥用 volatile：它只解决可见性，不解决原子性

减少锁范围：拆分共享状态，用 ThreadLocal 隔离线程视角

锁竞争本质是多个线程争同一块内存。如果能把共享状态按线程维度切开，就能彻底消除锁。比如数据库连接池里每个线程缓存一个连接，日志上下文里存 traceId，都适合用 ThreadLocal。

典型误用是把 ThreadLocal 当全局缓存用，或者忘了 remove() 导致内存泄漏（尤其在线程复用场景如 Tomcat 线程池）。

• 初始化用 withInitial(() -> new XXX())，避免每次 get() 都判空构造
• 在过滤器、拦截器或 finally 块中调用 threadLocal.remove()
• ThreadLocalRandom 是 ThreadLocal + Random 的优化组合，比全局 Random 实例快且无竞争

锁升级策略：从无锁 → 偏向锁 → 轻量级锁 → 重量级锁的真实影响

JVM 的锁优化不是黑盒。偏向锁在单线程反复进入同一同步块时省去 CAS 开销；但一旦出现多线程竞争，就会触发撤销（revoke），这个过程要 STW，反而更慢。所以高并发服务通常建议关闭偏向锁：-XX:-UseBiasedLocking。

轻量级锁靠 CAS 尝试替换对象头中的 Mark Word，失败则膨胀为重量级锁（内核态互斥量）。这意味着：频繁失败的 CAS 本身就有开销，且锁膨胀不可逆。

• 观察 -XX:+PrintGCDetails 和 -XX:+PrintSafepointStatistics 可发现偏向锁撤销是否频繁
• 热点同步块若被多个线程轮番进入，不如一开始就用 ReentrantLock 显式控制
• 对象逃逸分析开启后（-XX:+DoEscapeAnalysis），JIT 可能直接消除锁（锁消除），但这只适用于局部变量持有的锁

锁竞争不是越少越好，而是让等待时间尽可能短、唤醒路径尽可能直。真正难的不是选哪种锁，而是识别出哪些状态真的需要跨线程协调——其余的，尽量推给线程本地或无锁结构。

理论要掌握，实操不能落！以上关于《Java并发锁优化技巧详解》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！