Java变量线程安全取决于使用方式而非类型；volatile仅保证可见性与禁止重排序，不保证原子性；适合一写多读的原子操作场景，复合操作需用AtomicXxx、synchronized或Lock。

Java 中的变量是否线程安全，不取决于“是不是变量”，而取决于“怎么用”。普通变量在多线程下天然不安全，volatile 能解决部分问题，但不是万能的“线程安全开关”。

哪些变量容易出线程安全问题？

共享的、可变的、非原子操作的变量最危险。典型场景包括：

• 多个线程同时读写同一个实例字段（如 counter++）
• 一个线程修改对象状态，另一个线程依赖该状态做判断（如 isRunning = false 后仍继续执行）
• 对象引用被更新，但新对象的内部状态尚未完全初始化（发生指令重排序）

volatile 能保证什么？

volatile 关键字提供两项底层保障：

• 可见性：一个线程修改了 volatile 变量，其他线程立刻能看到最新值（绕过本地工作内存，直接读主内存）
• 禁止指令重排序：编译器和 CPU 不会将 volatile 读写操作与它前后的普通读写随意调换顺序

注意：它不保证原子性。例如 volatile int count; 的 count++ 仍是“读-改-写”三步，可能被中断，结果丢失。

什么时候适合用 volatile？

适用于“一写多读”且操作本身是原子的场景：

Java 接口排错助手

在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。

下载

• 状态标志位：volatile boolean shutdownRequested;
• 单次赋值的引用（如双重检查锁中的单例实例）：volatile Singleton instance;
• 数值类变量的简单读写（不参与复合运算），如计数器仅由一个线程递增、多个线程只读取

若需复合操作（如累加、条件更新），应改用 AtomicInteger、synchronized 或 Lock。

volatile 不行时，怎么办？

当需要原子性 + 可见性时，volatile 就不够了：

• 用 AtomicXxx 类（如 AtomicLong）替代基本类型，它们内部基于 CAS 实现原子操作
• 对临界区加锁：synchronized 方法或代码块，确保同一时刻只有一个线程执行
• 复杂逻辑或需等待通知时，考虑 ReentrantLock 配合 Condition

别为了“看起来轻量”强行用 volatile 替代同步机制——错用比不用更危险。

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南