对象锁锁this保护实例数据，类锁锁Class对象保护静态资源；二者互不阻塞，选择依据是数据归属：实例字段用对象锁，静态字段用类锁。
对象锁锁的是 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 等常量池对象，可能被其他代码意外共用
立即学习“Java免费学习笔记（深入）”；
类锁和对象锁的边界其实很清晰，但真正难的是在复杂业务里识别“这个数据到底归谁管”。很多并发 bug 不是锁没加，而是加错了粒度——比如该用类锁保护静态缓存，却只锁了实例方法，结果多个实例各自刷新，缓存雪崩。动手前，先问一句：我要同步的，是“每个对象自己的事”，还是“所有对象都得遵守的规矩”。
