登录
首页 >  文章 >  java教程

Java多线程同步方法与技巧

时间:2026-02-14 16:38:41 241浏览 收藏

本文深入剖析了Java多线程同步中极易被忽视却后果严重的实践陷阱:从synchronized(this)在单例、继承和对象发布场景下的锁边界失控,到volatile无法保障复合操作原子性的根本局限;从ReentrantLock与synchronized在锁释放、公平性、超时和调试可见性上的关键差异,再到ConcurrentHashMap的size()和isEmpty()为何返回“近似值”及其替代方案。文章不止于罗列规则,更引导开发者在每次加锁、读volatile、调用并发容器方法时,主动追问“我真正控制住什么?又放过了什么?”,将同步问题升华为对内存模型、锁作用域和工具设计契约的深度理解。

Java多线程中的同步问题与解决方案

为什么 synchronized 块里用 this 不一定安全

当多个线程操作同一个对象实例时,synchronized(this) 能保证该对象内临界区互斥;但若类被设计为可被多个不同引用访问(比如 Spring 管理的单例 Bean),或方法被子类重写后暴露了锁对象,就可能让外部代码意外持有同一把锁,造成阻塞扩散或死锁风险。

更常见的是误以为 this 锁能保护静态资源——它完全无效,因为静态成员属于 Class 对象,不是实例。

  • 只对当前实例有效,不作用于静态字段或其它实例
  • 如果对象被发布到多处(如作为参数传入、放入集合、被监听器引用),锁的边界就不可控
  • 推荐改用私有 final 对象锁:private final Object lock = new Object();,明确锁的作用域

volatile 不能替代 synchronized 的三种典型场景

volatile 只保证可见性和禁止指令重排序,不提供原子性。以下情况它完全无法解决同步问题:

  • 复合操作:如 counter++(读-改-写三步),即使 countervolatile,仍会丢失更新
  • 依赖检查再执行(check-then-act):如 if (list.isEmpty()) list.add(x);,判断和添加之间存在竞态窗口
  • 多个变量协同变化:如 ready = true; data = 42;,仅给 readyvolatile 不能确保 data 对其他线程及时可见(需 volatile + happens-before 链,或用锁)

ReentrantLock 和 synchronized 的关键取舍点

两者都支持可重入,但行为差异直接影响编码方式和错误排查路径:

  • synchronized 自动释放锁(JVM 保证),ReentrantLock 必须显式在 finally 块中调用 unlock(),漏写会导致永久阻塞
  • ReentrantLock 支持公平锁(构造时传 true),但性能显著下降;synchronized 非公平且不可配置
  • ReentrantLock 提供 tryLock(long, TimeUnit),可避免无限等待;synchronized 无超时机制,只能靠中断配合 wait()
  • 调试时,synchronized 的锁信息在 jstack 中显示为 - locked <0x...>,而 ReentrantLock 显示为 java.util.concurrent.locks.AbstractQueuedSynchronizer$Node,定位更难

ConcurrentHashMap 的 size() 和 isEmpty() 为什么不准

ConcurrentHashMap 为高并发设计,内部采用分段锁或 CAS,size()isEmpty() 返回的是**近似值**,不加全局同步就无法精确统计:

  • size() 在 JDK 8+ 中是遍历所有 bin 并累加,但过程中其他线程可能正在增删,结果可能偏高或偏低
  • isEmpty() 只检查第一个 bin 是否为空,其余段未扫描,返回 true 时未必真空
  • 若业务强依赖精确大小(如限流、批处理终止条件),应改用 mappingCount()(返回 long,仍是估算,但比 size() 更准),或引入额外计数器(用 AtomicLong 配合所有写操作)
Map<String, Integer> map = new ConcurrentHashMap<>();
// ❌ 不可靠
if (map.size() > 1000) {
    // 可能刚过 1000 就被清空
}
<p>// ✅ 更稳妥(仍非绝对精确,但语义更清晰)
if (map.mappingCount() > 1000L) {
// ...
}</p>

锁的粒度、可见性边界、工具类的“近似性”——这些不是文档里写清楚就能避开的坑,而是每次加锁、每次读 volatile、每次调 size() 时,得在脑子里多问一句:“此刻我真正控制住什么?又放过了什么?”

本篇关于《Java多线程同步方法与技巧》的介绍就到此结束啦,但是学无止境,想要了解学习更多关于文章的相关知识,请关注golang学习网公众号!

资料下载
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>