应根据业务粒度选择：方法级同步粗放易用但粒度大；代码块可精准控制临界区、减少竞争，但需谨慎圈定真正共享状态的操作，避免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<integer lock></integer>按 key 分段加锁，而不是一把锁管全部 - 确认是否真需要强一致性——有时最终一致+版本号更合适，别硬上锁
最常被忽略的一点：synchronized 解决的是可见性和原子性，但不解决业务逻辑的正确性。比如“检查再更新”（check-then-act）模式，即使加了锁，若中间有其他线程插入操作，仍可能出错——这时候得靠 CAS 或事务语义兜底。
