线程数失控本质是树形遍历逻辑与线程资源未对齐，需以线程状态（blocked/waiting占比）为动态反馈信号，反向约束dfs深度、分支数和任务生命周期，而非简单限流或扩容。
在多级组织架构图中做异步深挖时，线程数失控不是“并发太多”的表象问题，而是树形遍历逻辑与线程资源未对齐的系统性问题。核心解法不是粗暴限流，而是用线程状态监控作为动态反馈信号，反向约束 DFS 深度、分支数量和任务生命周期。
把线程状态当作深度控制开关
线程池不是黑盒容器，它的实时状态（如 BLOCKED 数陡增、RUNNABLE 持续满载、WAITING 线程堆积）是树遍历已超出承载能力的明确信号。不能等 OOM 或 CPU 100% 才响应，而应主动采集并触发降级：
- 每 500ms 调用
ThreadMXBean.dumpAllThreads(false, false)统计各状态线程数，重点关注 BLOCKED 和 WAITING 占比是否超 40% - 一旦检测到阻塞线程数 > 当前活跃线程数 × 0.3，立即冻结新任务提交，并将后续 DFS 深度上限从默认 20 降至 8
- 恢复条件不是“状态变好”，而是连续 3 次采样中 BLOCKED 比例回落至 10% 以下，才逐步放宽深度限制
为每个 DFS 分支绑定可中断的线程上下文
避免“一个深分支拖垮整池”。每个异步 DFS 任务必须携带可感知全局状态的执行上下文：
- 使用
IAsyncContext<traversalcontext></traversalcontext>封装当前深度、路径、起始时间、所属线程 ID - 在进入子节点前，检查
context.depth >= maxDepth || System.currentTimeMillis() - context.startTime > 3000，满足任一即终止该分支 - 配合
ExecutorService.invokeAll(tasks, timeout, unit)设置单分支最大耗时，超时自动 cancel，不依赖线程内主动退出
用线程组隔离+分层拒绝策略防雪崩
组织树扫描不能和业务请求共用同一套线程池。需按风险等级切分执行域：
- 创建专属线程组
new ThreadGroup("org-scan-group")，所有扫描线程归属其下，便于统一 list() 和 activeCount() - 配置两级拒绝策略：第一级拒绝新任务（抛
RejectedExecutionException并记录 warn）；第二级对已入队但 depth ≥ 12 的任务，在 execute 前直接 drop 并上报 metrics - 线程命名强制规范：
"org-scan-d{depth}-p{pathHash}"，例如"org-scan-d5-pa7f3"，方便 dump 时快速识别高深度任务源
物理线程数爆裂的本质是状态误判，不是数量不够
很多团队盲目扩容线程池到 200+，结果发现 WAITING 线程翻倍、GC 频繁——这说明瓶颈不在 CPU，而在 I/O 阻塞或锁竞争。此时加线程只会加剧资源争抢：
- 检查
ThreadInfo.getLockName()是否大量集中在某把锁（如组织节点缓存读写锁），优先优化临界区而非加线程 - 若多数 WAITING 线程停在
fetchChildren()，说明后端接口慢或未做熔断，应引入TimeoutThreadPoolExecutor包裹远程调用，而非扩大本地线程池 - 真正安全的“最大物理线程数” =
CPU 核心数 × (1 + 平均等待时间 / 平均工作时间)，对组织扫描这类混合型任务，通常取 2–4 倍核数即足够
