synchronized需严格约束：必须私有锁对象、最小化临界区、禁用外部/常量对象作锁、避免方法级大锁和静态同步滥用，严禁同步块内执行I/O等阻塞操作。
在企业级 Java 系统中，synchronized 不是“能用就行”的语法糖，而是需严格约束的底层同步原语。它直接关联系统吞吐、稳定性与可维护性——用得松散易引发性能瓶颈或隐蔽死锁；用得过重又增加架构耦合。核心原则是：**能不用则不用，必须用则最小化、显式化、可验证**。
锁对象必须私有且不可外部访问
禁止直接使用 this 或公开对象（如 public 字段、参数、返回值）作为锁目标。外部代码可能意外调用 wait()/notify()，或在其他上下文中加锁，导致不可控竞争或虚假唤醒。
- ✅ 正确做法：声明
private final Object lock = new Object();，仅在内部同步块中使用 - ❌ 错误示例：
synchronized (somePublicList) { ... }—— 若该 List 被其他模块遍历或修改，极易引发 IllegalMonitorStateException 或死锁 - ⚠️ 特别注意：避免用字符串字面量、Class 对象（除非明确需要类级别互斥）、或 Integer/Long 等常量池对象作锁——它们可能被不同模块无意共享
同步范围必须精确到临界区最小粒度
企业系统中常见反模式是“方法级大锁”：整个业务方法被 synchronized 包裹，但其中大量逻辑（如远程调用、日志打印、JSON 序列化）与共享状态无关。这会严重拖慢并发能力。
- ✅ 推荐写法：只对真正读写共享变量的几行代码加
synchronized(lock)块，其余逻辑移出同步区 - ✅ 替代方案优先级：无锁（CAS）、
java.util.concurrent工具类（如ConcurrentHashMap、AtomicInteger、ReentrantLock配合tryLock()）、读写锁（StampedLock）应优先于synchronized - ⚠️ 若必须用
synchronized方法，仅限极简场景：如单例 getInstance()、计数器 increment()，且方法体不含 I/O、循环、复杂计算
静态同步方法仅用于明确的类级全局状态
修饰静态方法等价于 synchronized(YourClass.class)，锁粒度为整个类——所有实例、所有线程共用一把锁。在微服务或多租户场景下极易成为瓶颈。
立即学习“Java免费学习笔记（深入）”；
- ✅ 合理用途：全局配置加载器的初始化、JVM 级资源注册（如 MBean 注册）、极少数跨实例强一致计数（需配合分布式锁评估）
- ❌ 滥用场景：用静态同步方法保护每个租户独立的缓存、用户会话、订单流水号生成器——应改为按租户 ID 分桶加锁或使用 ThreadLocal + 原子类
- ? 提示：若发现多个静态 synchronized 方法，应审视是否真需全局互斥，或可降级为细粒度对象锁 + ConcurrentHashMap 存储 per-key 锁对象
严禁在 synchronized 块内执行阻塞或长耗时操作
企业系统中典型陷阱：在同步块里调用 HTTP 接口、数据库查询、文件读写、sleep()。一旦发生网络抖动或慢 SQL，锁将长期持有，导致线程池饥饿、请求堆积、雪崩。
- ✅ 安全边界：同步块内只允许内存操作（读写字段、简单算术、集合 add/remove）、不抛异常的纯函数调用
- ✅ 必须外提操作：远程调用、DB 访问、序列化、加解密等一律放在同步块外，用局部变量暂存中间结果，再原子更新共享状态
- ⚠️ 高危组合：synchronized + wait() + 远程调用超时 —— 可能因未及时 notify 导致线程永久等待；建议改用
CompletableFuture或消息队列解耦
