synchronized通过锁机制与内存屏障协同保障原子性和可见性：原子性靠互斥执行确保临界区操作不可分割，可见性靠happens-before规则及StoreLoad等内存屏障强制刷新和重读共享变量。
synchronized 在 Java 内存模型（JMM）中，通过“锁机制 + 内存屏障”协同作用，同时保障操作的原子性和可见性。它不是单纯靠加锁完成的，背后有 JMM 的严格语义支持。
原子性：靠互斥执行保证
多个线程无法同时进入同一个 synchronized 代码块（或同步方法），因为 JVM 要求线程在进入前必须成功获取 monitor 锁；未获得锁的线程会被阻塞，直到锁被释放。这确保了临界区内的一组操作作为不可分割的整体执行。
- 对同一把锁（如某个对象实例或 Class 对象）的 synchronized 块，天然串行化执行
- 即使内部包含多条语句（如读-改-写），也不会被其他线程“插队”
- 注意：synchronized 不能保证不同锁保护的代码之间的原子性（例如两个 synchronized(this) 和 synchronized(other) 是独立的）
可见性：靠 happens-before 和内存屏障实现
JMM 规定：解锁操作（unlock）happens-before 后续对同一锁的加锁操作（lock）。这个 happens-before 关系，配合底层内存屏障，强制刷新共享变量的最新值。
- 线程 A 退出 synchronized 块时，会将工作内存中该锁保护的所有共享变量刷新回主内存
- 线程 B 进入同一把锁的 synchronized 块前，会清空本地工作内存，并从主内存重新读取这些变量的最新值
- 这种“写后读”的强制同步，由 JVM 在 monitorexit/monitorenter 指令插入内存屏障（如 StoreLoad 屏障）来实现
为什么 volatile 不行，而 synchronized 可以兼顾两者？
volatile 只能保证可见性和禁止重排序，但不提供原子性——比如 i++（读-改-写三步）用 volatile 修饰 i，依然可能丢失更新。synchronized 则天然包裹整个复合操作，既阻止并发执行，又确保结果对其他线程及时可见。
立即学习“Java免费学习笔记（深入）”；
- volatile 适合单次读或单次写场景（如状态标志位）
- synchronized 适合需要原子性+可见性的复合操作（如计数器增减、集合修改、状态转换）
- 从 JMM 角度看，synchronized 是更重但更完整的同步原语
实际使用要点
正确发挥 synchronized 的 JMM 效果，需注意锁对象的一致性与范围：
- 始终用同一个锁对象保护相关共享变量（如都用 this、或 private final Object lock = new Object()）
- 读写操作必须都在 synchronized 块内——只同步写、不同步读，读线程仍可能看到过期值
- 避免锁粒度过大（影响并发）或过小（失去保护意义），推荐细粒度锁（如按 key 分段锁）
- 静态同步方法锁的是 Class 对象，实例同步方法锁的是 this，二者不互斥
