Java变量线程安全取决于使用方式而非类型；volatile仅保证可见性与禁止重排序，不保证原子性；适合一写多读的原子操作场景，复合操作需用AtomicXxx、synchronized或Lock。
Java 中的变量是否线程安全，不取决于“是不是变量”，而取决于“怎么用”。普通变量在多线程下天然不安全，volatile 能解决部分问题，但不是万能的“线程安全开关”。
哪些变量容易出线程安全问题？
共享的、可变的、非原子操作的变量最危险。典型场景包括：
- 多个线程同时读写同一个实例字段（如 counter++）
- 一个线程修改对象状态，另一个线程依赖该状态做判断（如 isRunning = false 后仍继续执行）
- 对象引用被更新，但新对象的内部状态尚未完全初始化（发生指令重排序）
volatile 能保证什么？
volatile 关键字提供两项底层保障：
- 可见性：一个线程修改了 volatile 变量，其他线程立刻能看到最新值（绕过本地工作内存，直接读主内存）
- 禁止指令重排序：编译器和 CPU 不会将 volatile 读写操作与它前后的普通读写随意调换顺序
注意：它不保证原子性。例如 volatile int count; 的 count++ 仍是“读-改-写”三步，可能被中断，结果丢失。
立即学习“Java免费学习笔记（深入）”；
什么时候适合用 volatile？
适用于“一写多读”且操作本身是原子的场景：
- 状态标志位：volatile boolean shutdownRequested;
- 单次赋值的引用（如双重检查锁中的单例实例）：volatile Singleton instance;
- 数值类变量的简单读写（不参与复合运算），如计数器仅由一个线程递增、多个线程只读取
若需复合操作（如累加、条件更新），应改用 AtomicInteger、synchronized 或 Lock。
volatile 不行时，怎么办？
当需要原子性 + 可见性时，volatile 就不够了：
- 用 AtomicXxx 类（如 AtomicLong）替代基本类型，它们内部基于 CAS 实现原子操作
- 对临界区加锁：synchronized 方法或代码块，确保同一时刻只有一个线程执行
- 复杂逻辑或需等待通知时，考虑 ReentrantLock 配合 Condition
别为了“看起来轻量”强行用 volatile 替代同步机制——错用比不用更危险。
