对象锁与类锁区别详解

对象锁与类锁虽同属synchronized机制，但本质截然不同：前者锁定具体实例（this），用于保护实例变量和对象级状态；后者锁定Class对象（如MyClass.class），专为静态资源、全局配置或单例初始化而设——二者互不干扰、可并行执行，却常因混淆导致竞态、脏读或锁失效等隐蔽并发bug；真正关键不在“怎么加锁”，而在清醒判断“数据归属”：属于某个对象？用对象锁；属于整个类？必须升格为类锁，否则再严密的同步也形同虚设。

对象锁锁的是 this，类锁锁的是 MyClass.class

本质就一句话：对象锁保护实例数据，类锁保护静态资源。它们用的都是 synchronized，但“锁住谁”完全不同——synchronized 方法没加 static，锁的就是调用它的那个对象（this）；加了 static，锁的就是当前类的 Class 对象（比如 Demo.class）。

常见错误现象：
• 以为给两个不同对象的 synchronized 实例方法加锁，就能串行执行 → 实际是并发的，因为 new Demo() 和 new Demo() 是两把独立的锁
• 在静态工具类里误用实例方法同步 → 锁不住，因为没有实例，this 为空或不一致

实操建议：
• 想保护 this.count、this.cache 这类字段？用对象锁（非静态 synchronized 方法或 synchronized(this)）
• 想保护 private static int globalId 或做单例初始化？必须用类锁（static synchronized 或 synchronized(MyClass.class)）

对象锁和类锁能同时运行，互不阻塞

这是最容易误解的一点：一个线程拿着对象锁执行 instanceMethod()，另一个线程完全可同时拿到类锁执行 staticInit()。它们根本不是同一把锁，JVM 也从不协调这两者。

使用场景举例：
• Web 应用中，用户会话对象（UserSession）用对象锁控制其内部状态变更
• 同时后台线程在调用 ConfigLoader.reload()（静态同步），加载全局配置

容易踩的坑：
• 在对象锁方法里直接读写静态变量，却没额外同步 → 可能读到脏值或引发竞态
• 用 synchronized(obj) 锁了一个临时对象（比如 new Object()），每次新建 → 锁失效，形同虚设

怎么选？看你要保护的数据归属哪个作用域

判断依据非常直白：
• 数据属于某个具体对象？比如 order.totalPrice、cache.get(key) → 对象锁
• 数据属于整个类？比如 ConnectionPool.getInstance()、Logger.level、静态计数器 → 类锁

性能影响提醒：
• 类锁是全局限制，一旦高并发调用静态初始化方法，容易成为瓶颈
• 对象锁粒度更细，但若锁对象被频繁共享（如池化对象未隔离），也会意外扩大竞争范围

实操建议：
• 能用对象锁就别升为类锁，避免过度串行化
• 静态资源初始化优先考虑双重检查锁（DCL）+ volatile，比纯 static synchronized 更高效
• 不确定时，先跑个压测：对比 synchronized(this) 和 synchronized(MyClass.class) 的吞吐差异

代码块里显式指定锁对象，比修饰方法更灵活也更危险

方法级 synchronized 看似简单，但锁对象不可控；而 synchronized(obj) 块让你自己决定锁谁——这既是优势，也是隐患。

参数差异：
• synchronized(this) ≡ 非静态方法上的 synchronized
• synchronized(MyClass.class) ≡ 静态方法上的 synchronized
• synchronized(someField)：只要 someField 是 final 且不为 null，就安全；否则可能因引用变更导致锁失效

典型陷阱：
• 把锁对象设为可变引用（如 list = new ArrayList() 后又重新赋值）→ 下次同步块锁的是新对象，旧锁已丢
• 在 lambda 或匿名类中捕获并锁住局部变量 → 编译报错，Java 不允许锁局部变量

建议：
• 锁对象优先用 private final Object lock = new Object()，明确、可控、不暴露
• 避免锁 String、Integer 等常量池对象，可能被其他代码意外共用

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《对象锁与类锁区别详解》文章吧，也可关注golang学习网公众号了解相关技术文章。