局部内部类需捕获effectively final变量，优先封装为不可变对象；避免引用可变非线程安全对象，必要时防御性拷贝；警惕隐式this导致内存泄漏，推荐显式传参；threadlocal需快照值并手动清理。
在 Java 多线程中，局部内部类（Local Inner Class）本身不能直接“安全传递”外部上下文——它天然持有对外部方法栈帧中 final 或 effectively final 变量 的隐式引用。真正要解决的是：如何让局部内部类在异步/多线程执行时，仍能正确、线程安全地访问所需上下文数据，且不引发内存泄漏或变量竞态。
确保被捕获的变量是 effectively final
局部内部类只能访问所在方法中声明为 final 或编译期不可变（effectively final）的局部变量。Java 8+ 要求这一点，本质是为了避免多线程下变量状态不一致。
- 不要在启动线程后修改该变量（即使语法允许，也会导致逻辑错乱）
- 若需传递多个值，建议封装为不可变对象（如 record、自定义 final 类），而非多个独立变量
- 例如：record RequestContext(String traceId, int tenantId) {}，然后在方法内声明 var ctx = new RequestContext("t-123", 42);，局部类可安全捕获 ctx
避免捕获非线程安全的可变对象
即使变量本身是 effectively final，若其引用的对象是可变且非线程安全的（如 ArrayList、HashMap、StringBuilder），仍可能引发并发问题。
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 优先使用不可变容器（List.copyOf()、Collections.unmodifiableList()）或线程安全替代品（CopyOnWriteArrayList、ConcurrentHashMap）
- 若必须传入可变对象，应在局部类内部做防御性拷贝（deep copy 或 shallow copy，视语义而定）
- 切忌捕获正在被其他线程并发修改的集合或缓存实例
警惕隐式 this 引用与生命周期错配
局部内部类会隐式持有外部类实例（OuterClass.this）的引用。如果该外部类实例生命周期远长于线程任务（比如是 Spring Bean 或静态上下文），而局部类又在线程池中长期存活，就可能造成内存泄漏或状态陈旧。
- 若不需要外部类成员，显式声明为 static class（此时不是局部内部类，而是局部静态嵌套类），彻底切断对外部实例的引用
- 更推荐方式：将所需上下文明确提取为参数，通过构造器或方法参数传入 Runnable/Callable，避免依赖隐式引用
- 例如：用 new Task(ctx).run() 替代在局部类中直接读取 this.field
配合线程局部存储（ThreadLocal）补充上下文
当某些上下文（如用户身份、事务 ID、日志 MDC）需跨方法调用链透传，且无法或不便作为参数层层传递时，可用 ThreadLocal 做补充，但需主动管理生命周期。
- 在提交任务前，手动将上下文 set() 到 ThreadLocal；在线程执行结束前（尤其在线程复用场景如线程池中）务必 remove()
- 不要在局部内部类构造时捕获 ThreadLocal 实例本身——它只是工具，上下文值应提前快照（String tid = MDC.get("traceId")）再传入
- Spring 的 RequestContextHolder 或 Slf4j 的 MDC 就是典型应用，但底层仍依赖开发者正确 reset
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
