不推荐用 futuretask 实现类目树的全自适应子节点动态装配，因其仅适用于单次确定性异步任务，无法处理树形层级依赖、懒加载、缓存一致性及高并发场景；应采用服务端预聚合+缓存分层、前端懒加载与虚拟滚动等分层解耦方案。
电商分类侧边栏的类目树生成中，不推荐用 futuretask 实现“全自适应的子节点动态装配”。这不是 futuretask 的设计场景，强行使用反而引入线程安全、时序混乱、资源泄漏和响应不可控等问题。
FutureTask 的真实定位
FutureTask 是对单个异步计算任务的封装，适用于“提交一次、获取一次结果”的确定性耗时操作（如查一次数据库、调一次远程接口）。它不负责协调多个节点的依赖关系，也不管理树形结构的递归装配逻辑。
- 类目树天然具有层级依赖：父类目加载后，才知子类目 ID 列表；子类目加载完，才可递归加载其子节点
- “全自适应”意味着按需展开、懒加载、折叠态缓存、高并发访问下的一致性——这些靠 FutureTask 无法保障
- 若为每个节点都 new 一个 FutureTask，会快速耗尽线程池，且失败重试、超时熔断、结果合并等都要手动实现
更合理的技术路径
真正支撑动态、可伸缩、响应快的类目树，应分层解耦：
- 服务端预聚合 + 缓存分层：后台定时构建带深度限制（如 3 层）的轻量树结构，存入 Redis Hash 或 JSON 字符串；首屏只取一级，点击后再按 parent_id 查二级缓存
- 前端懒加载 + 虚拟滚动：侧边栏只渲染可视区域节点；展开某父类目时，前端发请求获取其 direct children（非整棵树），后端用单次 SQL JOIN 或分页查询返回，无需多线程编排
- 异步非阻塞替代方案：若真需后端异步组装（如组合商品标签+运营配置+权限过滤），用 WebFlux + Mono/Flux 或 CompletableFuture.supplyAsync 配合 thenCompose 处理链式依赖，比 FutureTask 更自然、可组合、易错误处理
如果坚持用 FutureTask（仅限教学或极简场景）
仅适用于“所有子节点无依赖、可并行拉取、且层级固定为 2”的简单情况，例如：已知一级类目列表，需并发查每个一级类目的二级子类目。
- 用 ExecutorService 提交一批 FutureTask，每个 task 封装一个 getChildren(Long parentId) 调用
- collect 所有 Future#get() 结果，再在主线程里拼成树节点（注意：get() 是阻塞的，要设 timeout）
- 必须显式 shutdown 线程池，且不能复用 request-scoped 的临时线程池，否则内存泄漏
- 无法处理某子类目查不到、或需 fallback 默认节点等业务逻辑——FutureTask 不提供回调钩子
不复杂但容易忽略：类目树的核心矛盾从来不是“怎么并发”，而是“怎么减少并发”——靠缓存、预热、分级加载、客户端状态协同，而非在线程模型上硬刚。
