java内存模型通过start()和join()规则建立天然happens-before关系：start()调用前的写操作对子线程可见；join()返回后，子线程所有操作对主线程可见，二者无需volatile或synchronized即可保障跨线程数据传递的内存可见性。
Java 内存模型（JMM）通过 happens-before 原则为多线程程序提供内存可见性和执行顺序的语义保障。线程启动规则（start()）和线程终止规则（join()）正是其中两条关键的“天然 happens-before 关系”，它们不依赖 synchronized 或 volatile，而是由 JVM 语言规范强制保证的内存语义。
线程启动规则：start() 方法先行发生于子线程所有动作
当线程 A 调用 threadB.start()，JMM 规定：线程 A 在调用 start() 之前对共享变量的所有写操作，对 threadB 启动后执行的任何代码都可见。
这背后不是靠锁或刷新缓存实现的，而是 JVM 在线程真正开始执行前，强制完成一次从主内存到新线程工作内存的“初始同步”——相当于隐式插入了内存屏障，确保子线程看到父线程 start() 前的最新状态。
- 注意：该规则只保障
start()调用前的操作可见，不包括之后的写操作（比如 start() 后再改某个变量，子线程不一定看到） - 典型误用：在
start()后才初始化共享配置对象，却期望子线程立即读到；正确做法是初始化完成后再调用start() - 它与 volatile 的可见性机制不同：start 规则是单次、一次性、启动时刻的同步，不是持续监听更新
线程终止规则：join() 返回意味着子线程所有操作已对主线程可见
当线程 A 调用 threadB.join() 并返回，JMM 保证：threadB 中执行过的所有操作（无论是否加锁、是否 volatile），都 happens-before 该 join() 方法的返回点。也就是说，线程 A 在 join() 返回后读取任何被 threadB 修改过的共享变量，一定能拿到最终结果。
本质是 join 实现中内置了同步语义：JVM 确保 threadB 终止时，其工作内存中所有变更已刷新回主内存；而线程 A 在返回前，会重新加载相关变量（类似隐式 read-load 序列）。
- 即使 threadB 中用普通变量（非 volatile）累加计数，A 在 join() 后读取该计数，也能看到完整结果
- 该规则也适用于
isAlive() == false或线程自然结束后的检测，但join()是最明确、最可靠的同步点 - 如果未调用 join()，仅靠 sleep 或轮询 isAlive()，无法获得此保证——那些操作不构成 happens-before 关系
start 和 join 的配合使用：构建可靠的数据传递链
二者常组合形成“生产-消费”式协作：主线程准备数据 → 调用 start() → 子线程处理 → 主线程 join() 等待 → 安全读取结果。
- 这个链条中，start() 保障“输入可见”，join() 保障“输出可见”，中间无需额外同步（除非子线程内部有并发修改）
- 例如：主线程设置
inputList = new ArrayList(...)，然后worker.start()；worker 处理完写入resultList；主线程worker.join()后遍历resultList—— 整个流程的内存可见性由 JMM 自动兜底 - 若 worker 内部还涉及多个子任务并行，那局部仍需 volatile/synchronized 控制，但主线程与 worker 的边界已由 start/join 守住
和 volatile、synchronized 的区别在哪
start/join 规则是事件驱动型同步：只在特定方法调用点建立一次性的 happens-before 链；而 volatile 提供的是持续可见性（每次读都拉取最新值），synchronized 提供的是临界区互斥+进入/退出时的内存同步。
- 不需要长期通信？用 start/join 更轻量，无运行时开销
- 需要反复读写同一变量？volatile 或锁更合适
- 它们不冲突，可共存：比如用 volatile 标记任务状态，再用 join 确保最终一致性
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
