synchronized 是 Java 基础同步机制，优点是语法简洁、JVM 保障原子性可见性、支持 wait/notify、低竞争下性能好；缺点是锁粒度粗、不支持超时中断、非公平、无法 tryLock 或多条件变量；适用于小方法、低竞争、无需高级特性的场景。
synchronized 是 Java 中最基础的同步机制，用于保证多线程环境下的线程安全。它简单直接，但也有明显局限。用得好能快速解决问题，用得不当则容易引发性能瓶颈或死锁。
优点：简单、可靠、内置支持
• 语法简洁，加个关键字就能锁定对象或代码块，不需要手动管理锁的获取和释放；
• JVM 层面保障原子性、可见性和有序性，不会出现“忘记 unlock”这类问题；
• 与 monitor 机制深度绑定，天然支持 wait/notify 等线程协作；
• 在低竞争场景下开销小，HotSpot 虚拟机做了多种优化（如偏向锁、轻量级锁）。
缺点：粒度粗、扩展性差、无法中断
• 锁只能是对象或类级别，不能像 ReentrantLock 那样灵活控制锁范围；
• 不支持超时获取锁（synchronized 会一直阻塞），也无法响应中断；
• 无法实现公平锁，线程调度完全依赖操作系统，可能造成线程饥饿；
• 锁升级失败（如大量线程竞争）会导致重量级锁，性能骤降；
• 无法尝试获取锁（没有 tryLock），也不支持多个条件变量（一个 synchronized 块只对应一个 wait set）。
适用场景：别过度设计，也别滥用
• 方法体小、竞争不激烈时，比如单例 getInstance()、计数器 increment()；
• 不需要超时、中断、公平性等高级特性；
• 快速原型开发或维护老代码，追求稳定而非极致性能；
• 作为学习并发原理的起点——理解 monitor、对象头、锁膨胀过程很有价值。
替代建议：该换的时候就换
• 需要超时控制？用 ReentrantLock.tryLock(long, TimeUnit)；
• 要响应中断？用 lockInterruptibly()；
• 多个等待条件？用 Condition 替代单一 wait/notify；
• 高并发读多写少？考虑 StampedLock 或 ReadWriteLock；
• 纯状态更新？优先用 AtomicInteger 等 CAS 类型。
基本上就这些。synchronized 不复杂但容易忽略它的隐式行为，用之前想清楚：是不是真需要它，有没有更轻量或更可控的方式。
