synchronized用法解析：同步方法与代码块详解

本文深入剖析了 Java 中 synchronized 的核心用法与实战陷阱，围绕同步方法与同步代码块的选择逻辑展开，强调应根据业务粒度精准控制临界区——方法级同步虽简洁但易导致锁粒度过粗、性能下降，而代码块同步虽灵活却需严防将 I/O、日志等非共享操作纳入锁内；同时揭示了锁对象误用（如局部 new 对象）、死锁隐患（多锁获取顺序不一致）、性能退化（高竞争触发重量级锁）等高频问题，并给出可落地的优化策略：优先无锁（AtomicInteger、ConcurrentHashMap）、分段加锁、固定锁序、tryLock 超时机制，以及清醒认知 synchronized 的边界——它保障原子性与可见性，却不保证业务逻辑天然正确，“检查-更新”类场景仍需 CAS 或事务兜底。

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

看业务粒度。方法级同步锁的是整个 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 或事务语义兜底。

好了，本文到此结束，带大家了解了《synchronized用法解析：同步方法与代码块详解》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多文章知识！