volatile修饰静态变量可解决并发可见性问题，通过强制读写主内存、禁止重排序及触发内存屏障，确保状态通知类场景（如running标志）的线程间立即可见。
Java类变量（即静态变量）在并发环境下出现不可见，本质是线程各自缓存了该变量的副本，未及时与主内存同步。解决的关键不是“加锁”或“改结构”，而是让读写操作强制穿透缓存、直连主内存，并建立明确的内存可见顺序。
用 volatile 修饰静态布尔开关变量
这是最轻量、最常用的方式，适用于“状态通知”类场景（如启动/停止标志）。
- 声明时加上 volatile：例如
private static volatile boolean running = true; - 它保证每次读取都从主内存加载最新值，每次写入立即刷回主内存，并使其他CPU核心缓存对应地址失效
- 适合单一赋值+单一检查逻辑，比如 while(running) 循环 + shutdown() 中设为 false
- 注意：不能用于复合操作（如
if (running && count > 0)），因为 count 的可见性不被 volatile 保障
用 synchronized 控制读写边界
当变量参与更复杂的业务逻辑（比如读-改-写），或需与其他操作保持原子性时，synchronized 不仅解决原子性，也天然解决可见性。
Java JDK 25
下载
Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。
- 进入同步块前，JVM 会强制从主内存刷新所有共享变量到当前线程工作内存
- 退出同步块时，会将修改后的变量值写回主内存
- 示例：对静态计数器做增减，应放在 synchronized 方法或代码块中
- 缺点是开销比 volatile 大，不适合高频、只读为主的场景
利用 final + 安全发布机制初始化静态对象
如果类变量是引用类型（如 static Config config），且只在类加载或首次使用时初始化，可用 final 配合静态内部类或静态块确保“构造完成即可见”。
- final 字段在构造器结束前写入，JMM 保证该对象对其他线程安全发布后，其 final 字段值一定可见
- 典型模式：静态内部类单例、static final 常量、static 块中初始化不可变对象
- 注意：final 只保障对象创建完成那一刻的字段可见性，不保障后续对对象内部状态的修改（除非对象本身不可变）
依赖 JMM 的 happens-before 规则构建显式顺序
在更底层或框架开发中，可通过显式建立 happens-before 关系来传递可见性，比如：
- volatile 写操作 happens-before 后续对该 volatile 变量的读操作
- 解锁（synchronized 退出）happens-before 后续对该锁的加锁
- 线程 start() happens-before 该线程的任何动作；线程 join() happens-before 调用方后续动作
- 这些规则不是语法糖，而是 JVM 和硬件必须遵守的内存语义契约，合理组合可避免过度同步
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
