同步块解决竞态需满足锁对象唯一、临界区完整、避开wait/notify冲突；推荐private final Object lock=new Object()；禁止new Object()或字符串字面量作锁；读写及复合操作须全包裹；避免同步块内耗时操作。
同步块能解决多个线程对共享变量的竞态问题，但前提是锁对象正确、临界区覆盖完整、且不与 wait/notify 逻辑冲突。
同步块的锁对象必须是同一个实例
用 new Object() 每次新建对象当锁，等于没锁；用字符串字面量（如 "lock"）依赖字符串常量池，风险高；推荐用 private final Object lock = new Object(); 声明在类成员位置。
- 错误写法：
synchronized (new Object()) { ... }—— 每次进块都拿新锁，完全失效 - 危险写法：
synchronized ("LOCK") { ... }—— 其他类也可能用同名字符串，导致意外串锁 - 安全写法：
synchronized (lock) { ... }，其中lock是 private final 成员变量
临界区必须严格包裹所有共享状态操作
只锁写不锁读、或漏掉某个字段更新，都会导致可见性或原子性破坏。比如对计数器 count 执行 count++，本质是读-改-写三步，必须整个包进同一把锁。
- 错误示例：先
synchronized更新count，再单独读取count—— 读操作可能看到过期值 - 正确做法：读、写、复合操作（如
if (count > 0) count--;）全部放在同一synchronized (lock)块内 - 注意：
volatile不能替代同步块，它不保证复合操作原子性
避免在同步块里调用外部可变逻辑或阻塞操作
同步块内调用第三方方法、I/O、网络请求或等待用户输入，会把锁持有时间不可控地拉长，极易引发线程饥饿甚至死锁。
立即学习“Java免费学习笔记（深入）”；
- 典型陷阱：
synchronized (lock) { doSomethingSlow(); }——doSomethingSlow()可能耗时几秒，其他线程全卡住 - 改进方式：把耗时操作移出同步块，只保留纯粹的状态变更逻辑
- 若必须等待结果，考虑用
ReentrantLock+tryLock(timeout)控制等待上限
真正难的不是加 synchronized，而是判断哪些状态算“共享”、哪些操作必须原子、以及锁的粒度是否刚好卡在业务语义边界上——这些往往只有在压测或并发异常复现时才暴露出来。
