线程安全问题的根源在于数据存放区域：私有区域（程序计数器、虚拟机栈、本地方法栈）天然隔离，共享区域（堆、方法区）天然竞争；JMM中工作内存与主内存的可见性断层进一步加剧风险，关键取决于引用是否逃逸导致共享。
线程安全问题的根源，不在代码写得是否谨慎，而在于数据存放在哪——是线程私有区域，还是线程共享区域。私有区域天然隔离，共享区域天然竞争，这是JVM内存模型给出的底层判定依据。
程序计数器、虚拟机栈、本地方法栈：私有即安全
这三个区域随线程创建而分配，随线程结束而释放，每个线程独有一份，彼此完全不感知。比如一个线程在虚拟机栈中压入了10个栈帧，另一个线程的栈里可能只有2个，它们的局部变量表、操作数栈互不影响。这种“朝生夕死”的生命周期决定了：只要变量只存在于栈帧的局部变量表中（例如方法内定义的int、String局部变量），就不可能出现多线程读写冲突。
常见误区是认为“方法内定义的变量一定线程安全”，其实前提是它没被逃逸出去——没作为返回值传出、没赋给静态字段、没发布到其他线程可见的容器中。一旦逃逸，哪怕初始在栈上，也可能被共享。
堆与方法区：共享即风险，需主动防护
所有new出来的对象实例、数组都分配在堆上；类信息、静态变量、常量池、JIT编译代码则存在方法区（JDK 8+为元空间）。这两个区域被所有线程直接访问，是线程安全问题的主战场。
例如一个public static List
解决方式不是避免使用堆，而是明确责任：共享对象必须由开发者保障其线程安全，手段包括：
- 使用线程安全的类（如CopyOnWriteArrayList、ConcurrentHashMap）
- 加锁（synchronized块或ReentrantLock）
- 用volatile修饰状态标志（适用于简单读写场景）
- 无状态设计或不可变对象（final字段+无修改方法）
工作内存与主内存：JMM视角下的可见性断层
JVM规范中的Java内存模型（JMM）进一步细化了“共享”的含义：主内存存放变量原始值，每个线程还有自己的工作内存（可理解为CPU缓存级副本）。线程对变量的读写都在工作内存中进行，不直接操作主内存。
这就引入第二层风险——可见性。比如线程A修改了一个共享变量并写回主内存，线程B可能还在用自己的旧副本工作，根本看不到更新。volatile关键字的作用，就是强制每次读都从主内存取，每次写都立刻刷回主内存；synchronized则在加锁和解锁时触发内存屏障，保证临界区前后的变量可见性。
注意：JMM中的“工作内存”不是运行时数据区里的某个物理区域，而是抽象概念，对应CPU缓存、寄存器等硬件层面的存储。它和线程私有区（如虚拟机栈）是不同维度的划分——前者讲线程与变量的交互规则，后者讲JVM内部内存的物理布局。
私有与共享的边界不是静态的，而是由引用传递决定的
一个对象诞生于堆（共享），但它的引用可以被限制在栈上（私有）。反之，栈上的局部变量如果把引用赋给了static字段，或者放进ConcurrentLinkedQueue这类跨线程容器，就瞬间完成了从私有到共享的跃迁。
因此，判断线程安全性不能只看变量声明位置，关键看引用是否“泄露”：
- 方法参数如果是对象引用，要警惕是否被保存或转发
- 返回值若为可变对象，调用方拿到后可能并发修改
- ThreadLocal本质是用线程私有Map包装共享对象，实现逻辑上的“伪私有”
真正安全的，不是“堆”或“栈”本身，而是数据的访问路径是否被有效约束。
