jmm不强制要求非volatile的long/double读写原子性，允许32位jvm将其拆分为两次32位操作，可能导致线程读到“撕裂值”；volatile仅保证单次读写不被拆分，不保证复合操作原子性，现代64位jvm通常天然原子。
Java 内存模型（JMM）对 long 和 double 这类 64 位变量的读写操作，**不强制要求原子性**——这是 JMM 明确允许的“宽松契约”，不是 bug，而是为兼容历史硬件（尤其是 32 位处理器）做的设计让步。理解它，关键在于分清“什么被允许撕裂”“什么场景真会出问题”“现代开发中是否还用得着担心”。
非原子性协议到底指什么
JMM 规定：对非 volatile 的 long/double 变量，JVM 可以将一次 64 位读或写，拆成两个独立的 32 位操作执行。比如：
- 写入
long x = 0x1234567890ABCDEFL，可能先写低 32 位0x90ABCDEF，再写高 32 位0x12345678 - 另一个线程此时读取
x，可能读到“高半部分是旧值、低半部分是新值”的拼接结果（如0x0000000090ABCDEF），即所谓“撕裂值”
注意：JMM 仅允许写操作被拆分；从 JDK 5（JSR-133）起，读操作必须原子——但前提是写操作本身没被其他线程中途打断。所以撕裂的本质，是读写交叉导致的中间态暴露。
哪些环境真会出现撕裂
撕裂不是理论风险，但在当前主流开发中已极难复现：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 32 位 JVM（如旧版 Windows x86 或嵌入式 Java ME）：最典型，
sun.arch.data.model输出32时需警惕 - 64 位 JVM（x86_64/aarch64）：现代 OpenJDK（8u292+、11、17、21）默认用单条 CPU 指令（如
mov rax, [mem]）完成 long/double 读写，天然原子 - 即使在 32 位环境，多数现代 JVM 实现也通过总线锁或 CAS 避开撕裂，而非依赖 volatile 补救
volatile 并不能“修复”原子性，只管单次读写的完整性
给 long/double 加 volatile，作用非常具体：
- 确保每次 单独的读或写 操作不可拆分（即避免撕裂）
- 同时带来可见性和禁止重排序，这是它的核心价值
- 但它不保证复合操作原子：如
counter++、if (x > 10) x *= 2依然线程不安全
换句话说，volatile 解决的是“值别拼错”，不是“操作别断掉”。要真正做计数、状态切换等，必须用 AtomicLong 或锁。
实际开发中该怎么做
不用猜，直接看运行时环境：
- 运行
System.out.println(System.getProperty("sun.arch.data.model")) - 输出
64→ 忽略 long/double 原子性问题，专注可见性与有序性 - 输出
32→ 若确实在维护老旧嵌入式系统，才需考虑 volatile 或 AtomicLong - 无论架构，只要涉及“读-改-写”逻辑，一律用
AtomicLong或同步机制，别依赖 volatile
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
