synchronized仅保证代码块或方法的互斥执行，临界区复杂性取决于共享资源、操作耦合度及多变量/外部调用/条件判断；关键在于精准定义原子操作范围并最小化锁粒度，避免在锁内执行IO、远程调用等耗时操作，必要时结合wait/notify或Atomic类补足功能。
synchronized 本身不处理逻辑，它只保证被它包裹的代码块或方法在同一时刻最多由一个线程执行。真正决定“临界区是否复杂”的，是你要保护的共享资源、操作步骤的耦合程度，以及是否涉及多个变量、外部调用或条件判断。处理复杂临界区的关键不是换锁，而是精准定义“什么必须原子执行”，再用 synchronized 合理围住它。
明确临界区边界：只锁真正需要互斥的部分
复杂逻辑常包含非共享操作（如日志、本地计算、HTTP调用），这些不该进 synchronized 块。否则会无谓拉长锁持有时间，拖慢吞吐量。
- 错误示例：把整个业务方法加 synchronized，里面混着数据库查询、远程接口、字符串拼接
- 正确做法：只对读-改-写共享状态的几行代码加锁，比如“查库存 → 判断是否充足 → 扣减 → 更新DB”中，仅“查库存”和“扣减”这两步若依赖同一份内存状态，才需放在同一把锁下；而更新DB本身可移出锁外（配合事务保证持久性）
- 建议用同步代码块而非同步方法，锁对象可选 private final Object lock = new Object();，避免锁住 this 或 Class 导致意外阻塞
多资源协同时，统一锁对象或分层加锁
当临界区涉及多个共享变量（如订单状态 + 库存数量 + 用户余额），必须确保所有访问路径都使用同一把锁，否则会出现部分更新、状态不一致。
- 不要让一部分逻辑锁 A，另一部分锁 B——即使 A 和 B 都是 Object 实例，它们互不感知
- 推荐为一组强关联资源定义专属锁对象，例如：private final Object inventoryBalanceLock = new Object();，所有修改库存+余额的逻辑都 synchronized(inventoryBalanceLock)
- 若资源间有明确依赖层级（如先锁账户再锁订单），需固定加锁顺序，防止死锁；但优先考虑单锁统一管理，比多锁协作更可靠
避免在 synchronized 内做阻塞或耗时操作
复杂临界区容易引入 sleep、wait、IO、远程调用等，这会让其他线程长时间等待，甚至引发超时或雪崩。
- 远程调用、DB 查询、文件读写一律移出 synchronized 块
- 如需“先检查再执行”的语义（如库存不足则拒绝），可在锁内完成判断并返回结果，把执行动作（如发MQ、记日志）放到锁外
- 必要时用 try-finally 确保锁释放，尤其在有异常分支的复杂逻辑中
结合其他机制补足 synchronized 的局限
synchronized 解决原子性和可见性，但无法表达“等待某个条件成立”。遇到 while-check、信号通知、超时重试等场景，要搭配 wait/notify 或更现代的工具。
- 简单等待（如库存恢复后重试）：synchronized 块内用 while + wait()，配合 notifyAll()，注意必须在锁内调用
- 需要超时、中断、公平性等高级控制：考虑 ReentrantLock + Condition，它提供更细粒度的等待队列
- 纯状态检查+简单更新（如开关、计数器）：用 AtomicInteger 或 AtomicBoolean 更轻量，无需锁
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
