Java 内存模型（JMM）中 volatile 的作用与限制

volatile关键字的主要作用是限制JVM进行指令重排，保证变量对其他线程的可见性，可以避免创建对象才完成了一半就被其他线程引用到这个对象，保证创建完成后才对其他线程可见。

static class Value {int x; // 默认 0
    Value() {// 模拟耗时初始化（增加重排序/竞态被观察到的概率）try { Thread.sleep(1); } catch (InterruptedException ignored) {}x = 42; // 正常初始化写在最后
    }
}// 非安全写法：instance 非 volatile
static class HolderUnsafe {Value instance;void init() {instance = new Value(); // 可能在某些重排序下，引用先可见而字段尚未写入
    }
}
public static void main(String[] args) throws Exception {final HolderUnsafe h = new HolderUnsafe();h.init();
}上面这段代码解析成字节码后可能是
public static HolderUnsafe init();0: getstatic     #2   // Field instance:LUnsafeSingleton;3: ifnonnull     246: new           #3   // class HolderUnsafe9: dup 10: invokespecial #4   // Method "<init>":()V13: putstatic     #2   // Field instance:LUnsafeSingleton;16: goto          024: getstatic     #227: areturn// Value() 构造器
public Value();0: aload_01: invokespecial #1   // Method java/lang/Object."<init>":()V4: aload_05: bipush        427: putfield      #5   // Field value:I10: return
注：
invokespecial #Method java/lang/Object."<init>":()Vaload_0把局部变量表索引 0 的引用加载到操作数栈
bipush 42 把一个有符号的 byte 常量（-128..127）推送为 int 到栈顶
putfield      #Field x:I 给对象实例设置字段值（非静态字段）。

字节码顺序（new / invokespecial / putstatic）看起来先完整构造再赋值，但这是在 Java 层面的指令序列，实际上顺序可能不是这样。
JIT 编译器与处理器、缓存系统可以在运行时做优化与重排序；在没有 volatile/同步的情况下，JMM 允许构造器对字段的写操作相对于对静态引用的写操作在可见性上发生重排序（或可见性延迟），从而使其他线程看到非空引用但字段仍为默认值。

可能的执行时间线（示意，A 为写线程，B 为读线程）：
线程 A (写入)
   [A1] 分配内存（object @0xABC）
   [A2] 在构造器中写入字段 value = 42（写入到 CPU 缓存 / 寄存器，尚未回写到主内存）
   [A3] 把引用写到 instance（putstatic），该写先被刷到主内存 / 对其它核心/线程可见
线程 B (读取，几乎同时)
   1.读取 instance，发现非空（看到了 A 的 [A3]）
   2. 读取 instance.value，此时由于 A 的 [A2] 尚未对 B 可见或被重排序，读到默认值 0 -> 半初始化现象

解决办法：

把 instance 声明为 volatile 或在创建/发布时使用同步（synchronized），volatile 在写入时会产生必要的内存屏障，保证构造器对字段的写入对其它线程在读取 instance 后可见，从而避免半初始化。

内存屏障是用于控制可见性与操作顺序的低层机制，语言层（volatile、synchronized、原子类）封装了这些屏障以保证并发正确性。

 

Spring 中的常见应用
  延迟初始化/单例发布（lazy singleton / DCL）：在自行实现延迟单例或发布代理/工厂引用时用 volatile 保证读到已初始化对象。
  发布缓存/引用替换：把构造完成的对象一次性赋给 volatile 字段以保证其它线程看到完整状态。
  生命周期/标志位：volatile boolean 做已初始化、已销毁、正在创建等状态标记以做快速无锁检查。
  读多写少的轻量可见性场景（替代不必要的同步）。
MyBatis 中的常见应用
  SqlSessionFactory 等延迟单例的 DCL（双重检查）字段用 volatile。
  Mapper 注册表 / 配置对象的引用替换发布（一次性构造并赋给 volatile 引用）。
  解析/加载标志（比如 parsed）防止重复解析（快速路径 + 同步块双重检查）。
  仅需可见性而非互斥时使用 volatile（降低同步开销）。

 

在 Spring/MyBatis 里，volatile 常用于发布已初始化的引用和状态标志，用以保证可见性与防止重排序；不使用时会引入半初始化、重复初始化或读取过期数据等难排查的并发错误。

MyBatis 启动时是否多线程？
   MyBatis 核心的 SqlSessionFactoryBuilder.build()/Configuration 构建在典型应用（手动或 Spring 启动）是单线程执行的。
    但在实际运行时有多种并发场景：Spring 多线程初始化 Bean（或插件/热加载）、多个线程并发首次访问懒加载的 Mapper、应用代码在运行期动态加载/解析 Mapper/资源等。这些场景会使解析逻辑可能被并发触发，因此需要线程安全的保护（volatile/同步/CAS）。ABA 问题指在线程使用比较并交换（CAS）检查某个变量时，变量从值 A 变为 B 又变回 A，CAS 只看值仍是 A，从而无法检测到中间发生了变化，可能导致错误的并发行为。

 

Spring bean的初始化是多线程的吗？

默认不是多线程的。
要点：
Spring 在容器刷新（ApplicationContext.refresh()）期间会调用 DefaultListableBeanFactory.preInstantiateSingletons() 预先实例化单例，这个过程默认在启动线程单线程完成（避免循环依赖与复杂依赖图的问题）。
如果开启懒加载（例如 Spring Boot spring.main.lazy-initialization=true）或在运行时多个线程并发第一次访问某个懒加载 Bean，那么 Bean 的创建可能由多个线程触发；Spring 在 DefaultSingletonBeanRegistry.getSingleton(...) 等机制上做了同步/阻塞保证，通常只会最终产生单个实例（其他线程等待或使用已发布的引用），但并不是并行初始化。
如果应用代码或自定义后处理器显式创建线程并并行调用 beanFactory.getBean(...)，就可能出现并发初始化，需要自己保证线程安全（或借助 Spring 提供的机制）。
总结：默认单线程初始化。只有在懒加载或应用层显式并发访问/并行化初始化逻辑时，才会出现多线程参与创建，且需注意同步、可见性与依赖顺序问题。

 

注意：

synchronized：提供互斥（mutual exclusion）和可见性。进入同步块时获取对象锁，退出时释放锁。
volatile：只保证可见性和有序性（内存屏障），不保证互斥。

Lock 接口（ReentrantLock 等）提供比 synchronized 更细粒度的控制（tryLock、可中断锁等），需在 finally 中释放锁。

原子类（java.util.concurrent.atomic.*，如 AtomicInteger/Long/Reference）使用 CAS 保证单变量的原子更新，性能高于加锁。原因是原子类使用 CPU 原子指令（CAS）实现无锁或自旋式更新，避免线程阻塞、上下文切换和内核调度开销，并在低争用时显著降低延迟与锁竞争开销。但在高争用或需要保证多个操作的复合原子性时，锁可能更合适；另有如 LongAdder 适合高并发累加场景。ABA 问题指在线程使用比较并交换（CAS）检查某个变量时，变量从值 A 变为 B 又变回 A，CAS 只看值仍是 A，从而无法检测到中间发生了变化，可能导致错误的并发行为。

 

什么时候用ThreadLocal 而不是加锁？

ThreadLocal 适合线程独占的状态/对象复用场景，能避免 synchronized 的锁竞争与阻塞，通常在性能敏感且每个线程需要独立副本时比 synchronized 更好。
如下列场景：
1.请求/会话级上下文保存：Web 请求链路中的 requestId、用户信息等，线程间不共享。
2.避免频繁创建/销毁代价大的对象，但又不能共享（线程内重用）。
3.高并发下对局部状态读写频繁，锁竞争成为瓶颈时。

4.MyBatis 会话/事务管理：MyBatis 的 SqlSession / 自定义会话持有器有时用 ThreadLocal 管理当前会话。

5.日志上下文（MDC）：SLF4J/Logback 的 MDC 本质上基于 ThreadLocal 保存 traceId 等，方便日志关联。