Java多线程数据不一致的根本原因是缺乏同步控制，导致非原子性操作、缓存可见性缺失和指令重排序；典型表现如i++丢失更新、volatile仅保可见性不保原子性、双重检查单例需volatile防半初始化对象。
Java多线程出现数据不一致，根本原因在于多个线程同时读写共享变量时，缺乏同步控制，导致操作的“非原子性”、缓存可见性缺失和指令重排序干扰。
共享变量被多个线程并发修改
当多个线程操作同一个对象的成员变量（如 static 或实例字段），而该操作不是原子的（例如 i++），就会出问题。i++ 看似一条语句，实际分三步：读取 i 值 → 计算 i+1 → 写回 i。若线程 A 读到 i=5，还没来得及写回，线程 B 也读到 i=5，两个线程都算出 6 并写回，最终 i=6 而不是预期的 7。
- 典型场景：计数器累加、状态标志更新、集合 add/remove
- 关键点：只要读-改-写过程未被锁或原子类保护，就可能丢失更新
CPU缓存与主内存不同步（可见性问题）
每个线程可能工作在自己的 CPU 缓存中。线程 A 修改了共享变量 value = 10，但只写到了本地缓存，还没刷回主内存；线程 B 从自己缓存或主内存读到的仍是旧值 value = 0，造成“看不到最新结果”。volatile 关键字能禁止缓存优化，强制每次读写都直达主内存。
- volatile 解决可见性，但不解决原子性（比如 volatile int i; i++ 仍线程不安全）
- synchronized、Lock、final 字段也能保证可见性，但机制不同
JVM 和 CPU 的指令重排序打乱执行顺序
为提升性能，编译器、JVM、CPU 可能对没有数据依赖的指令重排。例如对象初始化常被拆成：1) 分配内存；2) 初始化字段；3) 将引用赋值给变量。若重排为 1→3→2，另一个线程可能拿到一个“已赋值但未初始化完成”的对象，引发空指针或脏数据。使用 volatile 或 synchronized 可插入内存屏障，限制重排序范围。
立即学习“Java免费学习笔记（深入）”；
- 双重检查单例（Double-Check Locking）必须用 volatile 修饰 instance，否则可能返回半初始化对象
- happens-before 规则定义了哪些操作必须按序执行，是理解重排序约束的基础
线程切换导致执行逻辑断层
线程并非一直连续运行，操作系统会根据时间片调度切换。某个线程执行到一半被挂起，另一个线程介入并修改了共享状态，等它恢复时，基于过期上下文继续执行，结果自然错乱。这不是 bug，而是并发本质——必须靠同步手段（如 synchronized、ReentrantLock、CAS）把临界区变成“不可打断的最小执行单元”。
