多栏目看板采用“状态机驱动的动态线程池”架构：每个栏目独立状态机（init→fetching→rendering→standby→error），依状态事件实时调整隔离线程池参数，实现平滑缩放与精准告警。
多栏目看板的数据交互通常面临任务类型混杂、流量潮汐明显、响应延迟敏感三大特点。直接套用静态线程池容易在高峰时积压任务、低谷时空转耗资源，而状态机天然适合建模“栏目加载—数据拉取—渲染准备—异常回退”这类有明确阶段和转移条件的流程。将动态线程池与状态机绑定，核心不是让状态机去控制线程，而是用状态机的运行上下文驱动线程池参数的决策依据，实现真正贴合业务节奏的平滑缩放。
状态机定义任务生命周期，为缩放提供语义依据
每个栏目（如“实时订单”“库存预警”“设备健康”）对应一个独立的状态机实例，状态包括：INIT → FETCHING → RENDERING → STANDBY → ERROR。关键在于，状态转移不是简单标记，而是携带可观测指标：
- FETCHING → RENDERING：记录该次拉取耗时、返回数据量、下游服务RTT；若平均耗时 > 800ms 或失败率 > 5%，触发“IO型任务权重上升”信号
- STANDBY 持续超 30s：说明该栏目进入低频期，可降低其关联线程池的活跃线程保底值
- ERROR 累计 3 次/分钟：切换至降级状态，自动启用熔断线程池（仅保留 2 个线程+内存队列），避免拖垮整体资源
线程池按栏目隔离，参数由状态事件实时驱动
不共用一个大线程池，而是为每类栏目特征预设池模板，并通过状态事件动态绑定：
- CPU密集型栏目（如图表聚合计算）→ 绑定 FixedDynamicPool：核心=最大=CPU核数×1.2，仅允许动态调 keepAliveTime（状态为 STANDBY 时延长至 5min）
- IO密集型栏目（如多源API轮询）→ 绑定 ScalingDynamicPool：核心=4，最大=64，支持动态 setCorePoolSize / setMaximumPoolSize；当状态机发出“FETCHING 高频失败”事件，立即上调核心至 8，并切换队列为
ResizableLinkedBlockingQueue(容量×2) - 混合型栏目（如带本地缓存校验的查询）→ 绑定 HybridDynamicPool：内置双队列（优先级队列+普通队列），状态为 RENDERING 时，将渲染任务推入高优队列，保障首屏时间
缩放动作本身必须平滑，拒绝突变
线程数调整不是“跳变”，而是分步渐进，防止上下文切换风暴：
- 每次 resize 最多增减 2 个线程，间隔不少于 5 秒
- 扩容前先检查系统 load：若
load average / CPU核数 > 0.7，则暂缓扩容，改走队列积压告警路径 - 缩容只回收空闲线程：调用
pool.purge()清理已终止 Worker，再调setCorePoolSize(newVal)，避免误杀正在执行渲染任务的线程 - 所有调整操作记录 traceId 并写入审计日志，包含“触发状态”“前值/后值”“决策依据字段”
监控闭环：状态 + 线程池指标联合告警
单看线程池指标（如队列长度）易误判，必须叠加状态机维度：
- 告警规则示例：
栏目A 状态=FETCHING 且 队列积压 > 50 且 连续3次FETCHING耗时 > 1200ms→ 触发“IO瓶颈”告警，自动启动备用数据源线程池 - 大盘看板上，每个栏目卡片右上角显示实时小标：●（STANDBY+线程池空闲率>80%）、●（FETCHING+队列积压中）、●（ERROR+拒绝任务>0）
- 历史趋势图并列展示：状态转移频次曲线 vs 线程池活跃线程数曲线，二者强相关即说明策略生效
