父子线程无自动绑定，ThreadGroup不传递数据或生命周期，仅InheritableThreadLocal在new Thread时单次继承值，资源清理须手动，ScopedValue是Java 19+更安全的替代方案。
父子线程不是自动“绑定”的，ThreadGroup 不参与数据或生命周期传递
Java 里根本没有“线程组传播性”这种机制。ThreadGroup 是个被长期弱化的遗留类，它既不控制线程创建时的上下文继承，也不影响子线程的生命周期——父线程结束，子线程照常运行；父线程挂了，子线程不会被自动中断或回收。
常见错误现象：Thread.currentThread().getThreadGroup() 返回的只是逻辑分组，对调度、资源清理、异常传播全无作用。有人误以为把线程加进同一个 ThreadGroup 就能统一管理，结果发现 threadGroup.destroy() 根本杀不掉活跃线程，甚至抛出 IllegalThreadStateException。
- ThreadGroup 的
uncaughtException回调只在未捕获异常时触发，但不会阻止子线程继续执行 - 线程销毁依赖 JVM 自动回收栈帧和本地变量，ThreadGroup 不持有线程强引用，
destroy()实际只清空空闲子组，对运行中线程无效 - 现代代码（尤其用虚拟线程或
ExecutorService）几乎从不显式操作 ThreadGroup，JDK 自己都标记为@Deprecated(since="19")
InheritableThreadLocal 才是真正“传值”的地方，但只发生在 new Thread() 那一刻
父子线程之间唯一可靠的数据传递通道是 InheritableThreadLocal，但它不是靠 ThreadGroup，而是靠线程构造时的显式拷贝。关键点在于：这个拷贝只发生一次，在 new Thread() 构造函数执行期间，且仅当 inheritThreadLocals = true（默认 true）。
使用场景：Web 请求中主线程设好 userId，子线程做异步日志或消息发送时需要读取该值。
- 如果用线程池（如
Executors.newFixedThreadPool()），线程复用导致InheritableThreadLocal值残留——上一个任务留下的值可能污染下一个任务 - 虚拟线程（
VirtualThread）也支持继承，但需注意：JVM 在 fork 虚拟线程时仍走同一套createInheritedMap逻辑，所以行为一致 - 别指望
ThreadGroup能帮你“广播”更新——InheritableThreadLocal的值一旦子线程启动就固化，后续父线程修改不影响子线程
资源清理必须手动，父子线程之间没有隐式依赖关系
父线程退出，不会触发子线程的任何清理逻辑。文件句柄、数据库连接、Netty Channel 等资源，若子线程持有却没显式关闭，就会泄漏。这不是 JVM bug，是设计使然：线程间默认零耦合。
常见错误现象：主线程跑完就 return，后台子线程还在写日志到未关闭的 FileOutputStream，导致文件句柄持续占用，Linux 下 lsof -p PID 能清楚看到堆积。
- 用
try-with-resources包裹资源获取逻辑，但仅限于当前线程作用域内有效 - 若子线程需共享资源（如连接池），应通过参数传递或外部管理器（如
HikariDataSource）获取，而非靠父线程“传引用” - 虚拟线程虽轻量，但资源泄漏风险更高——成千上万个虚拟线程同时持有一个未关闭的
SocketChannel，比平台线程更早压垮系统
替代方案比 ThreadGroup + 继承更可控：ScopedValue（Java 19+）或显式上下文对象
如果你真需要跨线程传递上下文，ThreadGroup 是条死路，InheritableThreadLocal 容易踩坑，而 ScopedValue 是目前最干净的解法：它基于作用域而非线程绑定，自动随虚拟线程/平台线程的执行流传递，并在作用域退出时自动清理。
示例对比：
ScopedValue<String> userId = ScopedValue.newInstance();
ScopedValue.where(userId, "u123").run(() -> {
// 子线程内可直接 get()
Thread.ofVirtual().start(() -> System.out.println(userId.get())); // 输出 u123
}); // 作用域结束，值自动失效，无内存泄漏风险
-
ScopedValue不依赖线程构造时机，也不受线程池复用影响 - 不兼容 Java 19 以下版本，老项目只能退回到显式传参：把
Context对象作为参数塞进Runnable或Supplier - Spring 的
RequestContextHolder底层其实也是封装了InheritableThreadLocal，但加了 request 生命周期钩子来reset()，这说明：靠机制不如靠约定
真正麻烦的从来不是“怎么传”，而是“谁负责清”。ThreadGroup 连这个责任都不认，InheritableThreadLocal 把责任甩给开发者，ScopedValue 把责任交给 JVM —— 选哪个，取决于你敢不敢信那一行 where(...).run(...) 的括号闭合。
