应根据业务粒度选择：方法级同步粗放易用但粒度大；代码块可精准控制临界区、减少竞争，但需谨慎圈定真正共享状态的操作，避免I/O、日志等拖长锁持有时间。

同步方法和同步代码块，到底该选哪个？

看业务粒度。方法级同步锁的是整个 this（实例）或类对象（静态方法），粗放但易用；代码块能精准控制临界区，减少锁竞争，但得自己圈出真正要保护的逻辑。

常见错误是把整段含 I/O、日志、非共享变量的操作都塞进 synchronized 方法里——结果线程卡在日志打印上，别人干等着。

• 只对读写同一份共享状态的代码加锁，比如 counter++、list.add()
• 避免在同步块里调用外部服务或 sleep，这些会拖长持有锁的时间
• 静态方法用的是 MyClass.class 锁，和实例方法的 this 锁互不干扰

锁对象选错，为什么线程还是不安全？

因为锁对象必须是所有线程共用的。用局部变量、new 出来的对象、或每次调用都 new 的锁对象，等于没锁——每个线程都在锁自己的副本。

典型错误：在方法里写 Object lock = new Object(); synchronized(lock) { ... }，这锁完全不起作用。

• 实例共享状态 → 用 this 或私有 final 字段（如 private final Object lock = new Object();）
• 类级别共享状态 → 用 MyClass.class，别用 this.getClass()（子类可能打破一致性）
• 不要用字符串字面量或公共常量（如 "LOCK"）作锁，容易被意外共享

嵌套同步和锁顺序，怎么避免死锁？

两个线程分别持有一把锁，又去争对方手里的锁，就卡死了。Java 不会自动检测或中断这种死锁，程序就挂在那里，CPU 低、线程堆栈里全是 WAITING on java.lang.Object@...。

最容易踩的坑是：方法 A 同步后调用方法 B，而方法 B 又同步了另一个对象，且调用路径不统一。

• 所有涉及多把锁的操作，严格按固定顺序获取（比如总是先锁 lockA 再锁 lockB）
• 尽量避免在已持锁的情况下调用外部可重入的方法（尤其第三方库）
• 用 tryLock() + 超时替代无条件 synchronized，能主动退出争抢

为什么加了 synchronized，性能反而掉得厉害？

不是锁本身慢，是竞争高。当多个线程频繁进出同一把锁，JVM 会从轻量级锁升级到重量级锁，触发操作系统线程挂起/唤醒，开销陡增。这时候 synchronized 就成了瓶颈点。

看线程 dump：如果大量线程状态是 BLOCKED on java.lang.Object@...，基本可以确定是锁争用。

• 优先考虑无锁方案：如 AtomicInteger 替代 int counter，ConcurrentHashMap 替代 HashMap + synchronized
• 拆分锁：比如用 Map 按 key 分段加锁，而不是一把锁管全部
• 确认是否真需要强一致性——有时最终一致+版本号更合适，别硬上锁

最常被忽略的一点：synchronized 解决的是可见性和原子性，但不解决业务逻辑的正确性。比如“检查再更新”（check-then-act）模式，即使加了锁，若中间有其他线程插入操作，仍可能出错——这时候得靠 CAS 或事务语义兜底。