本质区别在于粒度与能力边界：synchronized 面向代码段，保障原子性、可见性、有序性；volatile 仅面向单变量，仅保障可见性与有序性，不保证原子性。
本质区别不在“用不用锁”，而在于解决并发问题的粒度和能力边界不同：synchronized 是面向“代码段”的完整同步方案，volatile 是面向“单个变量读写”的轻量协作机制。
作用目标不同：一个管“一段逻辑”，一个管“一个变量”
synchronized 锁定的是临界区——可能是几行代码、一个方法或整个对象。它确保这段逻辑在任意时刻只被一个线程执行，天然覆盖原子性、可见性、有序性三要素。
volatile 只能修饰变量，不涉及代码执行控制。它只干预该变量的读写行为：每次读都从主内存取最新值，每次写都立即刷回主内存，并插入内存屏障禁止重排序。
- synchronized 修饰方法 → 锁住 this 或类对象，阻塞其他线程进入该方法
- volatile 修饰 boolean running → 其他线程能立刻看到 running = false 的变化，但不能阻止两个线程同时执行 running = true 后的后续操作
保证的并发特性不同：原子性是关键分水岭
原子性是多线程下最易被忽略也最危险的一环。i++ 看似简单，实则包含“读-改-写”三步，中间可能被其他线程打断。
立即学习“Java免费学习笔记（深入）”；
- synchronized 能保证 i++ 整体不可分割：进入块时加锁，退出时解锁，期间无干扰
- volatile 无法阻止竞态：即使 int count 被声明为 volatile，多个线程同时执行 count++ 仍可能导致结果丢失
换句话说：volatile 让你“看见变化”，synchronized 让你“独占操作”。
运行机制与开销不同：阻塞 vs 非阻塞
synchronized 底层依赖 Monitor 锁，竞争激烈时线程会挂起（BLOCKED），涉及操作系统调度、上下文切换，有明显延迟成本。
volatile 不引发任何阻塞，靠 JVM 插入内存屏障指令实现同步，读操作几乎无额外开销，写操作略慢（因强制刷主存），但远低于锁的代价。
- 适合高频读+低频写的开关类场景（如 shutdown 标志）→ 用 volatile
- 涉及状态变更+业务逻辑组合（如库存扣减、订单创建）→ 必须用 synchronized 或更优的 Lock/Atomic
适用边界清晰：不是替代，而是分工
两者不是“谁更好”，而是“谁更适合”。真实系统中常协同使用：
- 双重检查单例中，instance 必须 volatile —— 防止 new Singleton() 指令重排导致其他线程拿到未初始化完成的对象
- 但 getInstance() 内部仍需 synchronized 块 —— 保证 instance 初始化过程的原子性
- 状态机中 running 标志用 volatile，而状态迁移逻辑（如从 RUNNING → STOPPING）需 synchronized 保护
选错会导致隐蔽 bug：用 volatile 替代锁，看似快了，实则数据错乱；过度用 synchronized，看似安全，实则吞吐骤降。
