Java多线程安全关键在于遵循JMM语义规则：用final保证安全发布、volatile控制可见性与重排序、synchronized/Lock建立happens-before关系、防御性拷贝避免状态逸出，所有同步手段都是对JMM边界的显式声明。
Java 多线程并发编程要真正规避安全隐患，不能只靠“加锁”或“猜行为”，关键在于理解并主动配合 JVM 内存模型（JMM）的语义规则。JMM 不是抽象理论，它定义了变量读写、可见性、重排序的边界——所有安全手段（volatile、final、synchronized、锁、原子类）都是对这些边界的显式声明。用错机制，或在不该放松的地方放松，就会埋下隐患。
用 final 保证构造完成即安全发布
对象在构造中逸出（如 this 引用被传出去）是最隐蔽的风险之一。JMM 规定：只要所有字段用 final 声明，且构造器内不发生 this 逸出，那么该对象一旦构造完毕，其字段值对其他线程就立即可见——无需额外同步。
- 避免在构造器里启动线程、注册回调、调用外部方法传
this - 若需延迟绑定，改用静态工厂方法 + 独立初始化（如
create().init()） - 内部类优先选
static；非静态内部类若必须持有外围实例，确保外围实例已构造完毕
用 volatile 控制可见性与禁止重排序
volatile 不是万能锁，但它是 JMM 提供的轻量级同步契约：写 volatile 变量会强制刷回主内存；读 volatile 变量会强制从主内存重载，并插入内存屏障阻止相关指令重排。
- 适合状态标志位（如
running = false）、单次写入后只读的引用（如延迟初始化的单例引用） - 不能用于复合操作（如
counter++），因为读-改-写三步不原子 - 双重检查锁单例中，必须用
volatile修饰实例字段，否则可能看到未完全初始化的对象
用 synchronized / Lock 建立 happens-before 关系
进入 synchronized 块前，JMM 保证线程清空本地工作内存；退出时，强制将修改刷回主内存。这建立了明确的 happens-before 关系，既解决可见性，也保障原子性。
立即学习“Java免费学习笔记（深入）”；
- 锁对象要稳定且唯一（推荐私有 final 对象，而非
this或getClass()） - 临界区尽量窄：只包裹真正共享数据的操作（如只锁
count++，不锁整个循环） - 可替换为
ReentrantLock，支持可中断、超时、公平性等更细粒度控制
防御性暴露可变状态，切断逸出路径
即使对象本身安全构造，若通过 getter 暴露内部可变容器（如数组、ArrayList），外部线程仍可绕过封装直接修改，造成状态污染。
- 返回集合时用
Collections.unmodifiableList(list)或深拷贝 - 不要返回私有数组引用，应返回
Arrays.copyOf(array, len) - 共享可变状态优先用线程安全容器（
ConcurrentHashMap、CopyOnWriteArrayList） - 最彻底的方式是设计不可变对象：所有字段
final，无 setter，内部可变组件做防御性拷贝
本质上，规避线程安全隐患不是堆砌同步，而是让每一步共享都符合 JMM 的契约：要么用 final/ volatile 告诉 JVM “这个我按规范来”，要么用锁/原子类“把这段逻辑打包成一个不可分割的动作”。写代码时多问一句：“这个引用或值，其他线程看到时，是否一定是我期望的状态？”——答案来自 JMM，而不是直觉。
