线程对象不可复用，对象池应复用无状态业务组件；需用scheduledexecutorservice定时清理空闲池对象，而非轮询terminated线程状态。
这问题实际混淆了几个关键概念，需要先理清：线程对象（Thread）本身不可复用，一旦进入 TERMINATED 状态就不可恢复或重用；对象池复用的是“可重复初始化的资源封装体”，而非原生线程实例；后端富文本解析逻辑与线程生命周期管理属于正交关注点——它们不该耦合在同一个组件里。
明确线程状态与对象池的职责边界
Java 中 Thread 是一次性对象：启动后只能经历 NEW → RUNNABLE → BLOCKED/WAITING/TIMED_WAITING → TERMINATED，且不可逆。所谓“剔除 TERMINATED 线程”不是回收线程，而是清理对已终止线程的引用（避免内存泄漏），或从线程池中移除失效的工作者包装器。
- 如果你用的是
ThreadPoolExecutor，它内部已自动管理 Worker 对象的创建、运行与销毁，无需手动轮询TERMINATED状态 - 若自行实现对象池（如复用
ParserContext、HtmlSanitizer实例等富文本处理上下文），池中存放的应是无状态/可重置的业务组件，而非Thread - 真正需要定时清理的，是池中长期闲置、超过最大空闲时间（如 5 分钟）且未被标记为“活跃”的池化对象
用 ScheduledExecutorService 定时清理空闲池对象（非线程）
假设你有一个自定义对象池，用于复用富文本解析所需的 DOM 构建器或 AST 缓冲区：
- 每个池化对象持有一个
lastUsedTime时间戳，在borrow()时更新，在return(obj)时重置 - 启动一个后台调度器：
ScheduledExecutorService cleaner = Executors.newSingleThreadScheduledExecutor(); - 每 30 秒执行一次清理：
cleaner.scheduleAtFixedRate(this::evictExpired, 0, 30, TimeUnit.SECONDS); -
evictExpired()遍历池内对象，移除System.currentTimeMillis() - lastUsedTime > idleTimeout的条目，并调用其reset()或close()方法释放内部资源
避免轮询 Thread.getState() —— 这是反模式
主动遍历所有线程并调用 getState() == Thread.State.TERMINATED 不仅开销大、易竞态，还违反 JVM 线程管理契约：
- JVM 不保证 TERMINATED 线程能被枚举到（尤其使用虚拟线程时）
- 线程退出后，JVM 自动解除其栈帧、释放本地内存，无需你“手动剔除”
- 若你发现大量 TERMINATED 线程堆积，真实问题是：线程未被正确 join 或未被线程池统一管理，导致
Thread实例被长期强引用（如存入静态 Map） - 解决方式是改用
CompletableFuture或ExecutorService提交任务，用Future.cancel(true)控制生命周期，而不是持有原始Thread引用
富文本解析场景下的推荐架构
将解析逻辑与线程管理解耦，聚焦业务对象复用：
- 用
ThreadLocal<jsoupparser></jsoupparser>或对象池提供轻量级 HTML 解析器实例（支持 reset()） - 解析任务统一提交给固定大小的
ForkJoinPool.commonPool()或专用ThreadPoolExecutor - 对超时任务，通过
Future.get(3, SECONDS)捕获TimeoutException，再触发上下文清理，而非监控线程状态 - 若需统计“失败解析数”，记录在业务指标（如 Micrometer Counter），而非靠线程状态推断
