threadgroup 在现代 java 中基本不用，它是 jdk 1.0 的遗留设计，已被 executorservice 等机制替代；仅在 jvm 启动默认组、老框架及隐式线程归属等场景出现，不适用于线程池或生命周期管理。
ThreadGroup 在现代 Java 里还用得着吗
基本不用，ThreadGroup 自 JDK 1.0 就存在，但自 ExecutorService 普及后，它就退居幕后了。JDK 文档明确标注为“legacy”，不是 bug，是设计上被替代了。如果你在新项目里手动 new ThreadGroup，大概率是在重复造轮子，或误读了老代码的意图。
哪些地方还能撞见 ThreadGroup
常见于三类场景：JVM 启动时默认创建的 system 和 main 组、某些老框架（如早期 Tomcat 线程管理）、以及 Thread 构造时未显式指定组时的隐式归属。你查 Thread.currentThread().getThreadGroup()，大概率看到的是 main；用 jstack 看线程快照，顶层分组名也常是 main 或 system。
- 不要试图用
ThreadGroup实现“线程池”——它不管理生命周期，也不复用线程 -
activeCount()和enumerate()返回值不可靠：只反映调用瞬间状态，且不递归子组，多线程下极易过期 -
destroy()几乎没用：要求组内无活线程且无子组，现实中几乎无法满足，调用后大概率抛IllegalThreadStateException
ThreadGroup.uncaughtException 的实际意义
这是目前最可能被主动用到的地方：给一组线程统一设置未捕获异常处理器。但它和 Thread.setDefaultUncaughtExceptionHandler() 是并列关系，不是替代关系——前者只对显式属于该组的线程生效，后者兜底所有未设置专属 handler 的线程。
ThreadGroup group = new ThreadGroup("my-group") {
@Override
public void uncaughtException(Thread t, Throwable e) {
System.err.println("Group " + getName() + " caught: " + e);
}
};
new Thread(group, () -> { throw new RuntimeException("boom"); }).start();
- 若线程构造时没传
ThreadGroup，它不会自动进你新建的组，仍走默认逻辑 - Lambda 创建的线程默认归属当前线程的组，不是你新建的那个
- Spring Boot 等容器已接管全局异常处理，再手动设
uncaughtException容易冲突
为什么 ThreadGroup 没被删掉
主要是 JVM 内部依赖和二进制兼容性。比如 Thread 构造函数签名里一直保留 ThreadGroup 参数，去掉会破坏所有字节码；jconsole、jstack 的线程视图也基于它做分组展示。但这些都不构成你在业务代码里主动用它的理由。
立即学习“Java免费学习笔记（深入）”；
真正容易被忽略的是：当你用 Thread.setDaemon(true) 时，这个 daemon 标志是线程自身的属性，跟它所属的 ThreadGroup 无关；而 ThreadGroup 自己也有个 daemon 属性，但它只影响“该组能否被 destroy”，和线程生死毫无关系——这点连很多老手都会想当然搞混。
