登录
首页 >  文章 >  java教程

synchronized线程安全原理与锁机制详解

时间:2026-02-07 22:18:45 264浏览 收藏

亲爱的编程学习爱好者,如果你点开了这篇文章,说明你对《synchronized如何保证线程安全?Java锁机制解析》很感兴趣。本篇文章就来给大家详细解析一下,主要介绍一下,希望所有认真读完的童鞋们,都有实质性的提高。

synchronized通过JVM的monitor机制实现互斥,线程需获取对象关联的monitor锁才能执行同步代码,锁的是对象而非代码块,支持重入且推荐细粒度的同步块而非方法级同步。

在Java里synchronized关键字如何保证线程安全_Java内置锁机制解析

为什么synchronized能阻止多个线程同时执行同一段代码

synchronized 本质是基于 JVM 的 monitor(监视器)机制,每个对象都有一个与之关联的 monitor。当线程执行 synchronized 块或方法时,必须先获取该对象的 monitor 锁;获取失败就阻塞等待,直到持有锁的线程释放它。这保证了临界区(critical section)的互斥访问。

注意:锁的是“对象”,不是代码块本身。所以两个线程调用不同对象上的同步实例方法,不会互相阻塞;而调用同一个对象的同步方法,才会排队执行。

  • synchronized(this) 和同步实例方法等价,锁的是当前实例对象
  • synchronized(ClassName.class) 或同步静态方法,锁的是类的 Class 对象,对所有实例全局唯一
  • 锁重入(reentrant):同一线程可多次进入同一把锁保护的区域,JVM 会维护锁计数器

synchronized 方法 vs synchronized 块:选哪个更合理

方法级同步粒度太粗,容易造成不必要的阻塞。比如一个长方法里只有几行要保护,却让整个方法串行执行,吞吐量明显下降。

推荐优先使用同步块,明确指定锁对象和保护范围:

public void transfer(Account from, Account to, BigDecimal amount) {
    // 只对账户余额操作加锁,不锁整个方法逻辑
    synchronized(from) {
        synchronized(to) {
            from.balance = from.balance.subtract(amount);
            to.balance = to.balance.add(amount);
        }
    }
}
  • 避免死锁:若需多把锁,始终按固定顺序(如对象哈希值排序)获取
  • 不要用 thisString 字面量作锁对象——前者可能被外部误用,后者因字符串常量池共享易引发意外竞争
  • 尽量用私有 final 对象作锁,比如 private final Object lock = new Object();

常见误用:看似加锁,实则无效的写法

以下几种情况,synchronized 看似存在,但根本没起到线程安全作用:

  • 同步方法但锁对象不一致:两个线程分别操作 new Counter() 的不同实例,synchronized 实例方法互不影响
  • 锁的是可变引用:比如 synchronized(list),但 list 被重新赋值过,后续加锁对象已变
  • 读操作没加锁:写用 synchronized,读却是普通方法,JVM 可能因指令重排或缓存导致读到脏数据(虽然 happens-before 存在,但非 volatile + 同步配对时仍易出错)
  • 锁住的是基本类型包装类(如 Integer):自动装箱导致每次都是新对象,锁失效

典型错误示例:synchronized(new Integer(1)) { ... } —— 每次都新建锁对象,完全无意义。

性能开销和替代方案的取舍点

在 JDK 6 之后,synchronized 经过大量优化(偏向锁、轻量级锁、自旋、锁消除、锁粗化),在无竞争或低竞争场景下性能接近甚至优于 ReentrantLock。但仍有不可忽视的边界:

  • 无法实现超时获取锁(tryLock(long, TimeUnit))、中断响应、条件变量(Condition)等高级控制
  • 锁的释放只能由 JVM 在退出同步块/方法时自动完成,不能手动控制
  • 高竞争下仍可能触发重量级锁膨胀,导致线程挂起/唤醒开销显著上升

真正需要细粒度控制、公平性、或配合条件等待时,才应切换到 ReentrantLock;日常简单互斥,synchronized 更简洁、不易出错,也更难写出死锁逻辑(因为隐式释放)。

最容易被忽略的是:锁的粒度和生命周期必须匹配业务语义。比如缓存加载场景中,用单个锁保护整个缓存 map,会成为瓶颈;改用分段锁或 ConcurrentHashMap 才是正解——这时候再纠结 synchronized 性能就没意义了。

文中关于的知识介绍,希望对你的学习有所帮助!若是受益匪浅,那就动动鼠标收藏这篇《synchronized线程安全原理与锁机制详解》文章吧,也可关注golang学习网公众号了解相关技术文章。

前往漫画官网入口并下载 ➜
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>