对象锁和类锁互不阻塞，因锁对象不同（this vs 类.class）；对象锁仅限同一实例，类锁全局唯一；应缩小锁粒度、选稳定锁对象、按共享变量类型匹配锁机制。
对象锁和类锁根本不会互相阻塞
这是最常被误解的一点：一个线程持有 synchronized 实例方法（对象锁），另一个线程完全能同时执行 static synchronized 方法（类锁），两者互不感知。因为它们锁的是两个完全不同的对象——一个是 this，一个是 Demo.class。
常见错误现象：
• 写了个 synchronized void inc() 和一个 static synchronized void reset()，以为调用 reset() 会等所有 inc() 执行完 → 实际不会。
• 在单例类里混用两种锁，结果发现计数器没被真正保护住。
- 对象锁只对同一实例有效；换一个
new Demo()，锁就失效 - 类锁作用于整个类，不管你是
new Demo().staticMethod()还是直接Demo.staticMethod()，都抢同一把锁 - 如果想让“所有实例的某个操作”全局互斥，必须用类锁（或显式用
Demo.class作同步块目标）
什么时候该用同步代码块而不是同步方法
同步方法锁住的是整个方法体，哪怕只有前 3 行代码需要保护，后面 20 行全是日志打印或 IO，也会把其他线程卡住。这直接拖慢并发吞吐量。
实操建议：
• 把锁范围缩到最小，只包真正读写共享变量的那几行
• 避免在 synchronized 块里做 System.out.println()、Thread.sleep()、网络调用、文件读写
- 错例：
synchronized void process() { log("start"); data++; log("done"); }→ 日志不该进锁 - 对例：
void process() { log("start"); synchronized(this) { data++; } log("done"); } - 更优：若
data是静态字段，锁应为Demo.class，而不是this
锁对象选错导致同步失效的典型场景
锁对象必须是稳定、唯一的引用。一旦锁对象本身被重新赋值、或每次调用都 new 出新对象，同步就形同虚设。
常见错误现象：
• 用局部变量当锁：synchronized(new Object()) { ... } → 每次都是新对象，毫无互斥效果
• 用可变引用当锁：private Object lock = new Object(); 然后某处写了 lock = new Object(); → 后续线程锁的不是同一个对象
- 安全做法：锁对象声明为
private final Object lock = new Object(); - 静态资源保护优先用
MyClass.class，比自己 new 一个static final Object更清晰、不易误改 - 不要用
String、包装类（如Integer）或数组当锁——它们可能被意外共享或 intern，引发意外交互
性能影响：锁粒度越粗，并发越低
对象锁比类锁“轻”，但多个实例之间又互不干扰；类锁最重，但它是唯一能跨实例强制串行的手段。没有“哪个更好”，只有“是否匹配你的临界区语义”。
关键判断点：
• 共享变量是实例字段？→ 优先对象锁（或 this 锁）
• 共享变量是静态字段？→ 必须类锁（static synchronized 或 synchronized(MyClass.class)）
• 多个字段需原子组合更新？→ 锁必须覆盖全部字段读写，且锁对象要统一
- 反模式：对
count++用对象锁，但对totalCount++（静态）用另一把锁 → 二者逻辑耦合却无同步保障 - 小技巧：用 JOL（Java Object Layout）工具看看锁膨胀过程，确认是不是真到了重量级锁阶段
- 真正影响性能的往往不是 synchronized 本身，而是锁竞争时线程频繁挂起/唤醒，以及缓存行伪共享等问题
最容易被忽略的是：锁的语义必须和业务一致。比如“用户余额扣减”和“订单创建”看似无关，但如果共用一个账户 ID 作为锁对象，就得确认这个 ID 是否真能代表业务上的排他边界——否则再细的粒度也没用。
