局部变量不会发生内存交叉污染，因其存储在各自线程的独立栈帧中；所谓“死结”实为误调用t.run()导致逻辑串行，并非内存污染，而是共享变量未同步引发的线程安全问题。
这个问题本身存在概念混淆，需要先厘清关键事实：
局部变量根本不会发生“内存交叉污染”
局部变量存储在每个线程自己的栈帧中，天然隔离。主线程的局部变量和子线程的局部变量物理上不在同一块内存区域，不存在交叉或污染可能。
- 你写
t.run()，所有代码仍在主线程执行，所有局部变量都压在主线程栈上 —— 没有“另一个线程栈”，也就谈不上“交叉” - 真正启动线程（
t.start()）后，JVM 会为它分配独立的虚拟机栈（对应 OS 线程栈），局部变量自动隔开 - 所谓“死结”，其实是逻辑串行导致的并发失效，不是内存污染
你以为的“污染”，实际是共享变量未同步
如果多个线程（或看似多线程实则单线程串行）修改了同一个 成员变量、静态变量或外部传入的可变对象，才可能出现数据错乱。这才是真正的线程安全问题。
- 例如：两个
Runnable实例共用一个ArrayList，又没加锁，就可能抛ConcurrentModificationException或丢失更新 - 修复方式不是“处理污染”，而是明确数据归属：该用局部变量就别外提，该同步就加
synchronized或用java.util.concurrent工具类
正确启动线程才是解法起点
只要把 t.run() 改成 t.start()，让逻辑真正在新线程运行，局部变量自然各管各的栈，根本不会混。
- 检查是否误调用了
run()：搜索代码中.run()调用，确认上下文是不是本该用.start() - 验证线程身份：在疑似“污染”的位置打印
Thread.currentThread().getName()，看是否始终是main - 避免手动管理线程生命周期：优先使用
ExecutorService，靠submit(Runnable)启动，不易出错
本质上，这不是内存模型层面的死结，而是启动方式错误引发的逻辑误解。修正启动方式，问题就消失了。
