多栏目看板线程数自适应采用每栏目独立并发安全状态机，封装状态、指标与隔离线程池，状态流转直接驱动线程池参数调整，缩放平滑可控且可观测，通过注解+AOP实现业务代码零侵入。

在多栏目看板中，线程数自适应的关键不是统一调控，而是让每个栏目“自己管自己”——用并发安全的状态机为每个栏目建模生命周期，再把状态变化直接映射为线程池参数调整动作。状态即策略，流转即指令。

每个栏目一个独立状态机对象

不共用状态机实例，而是为“实时订单”“库存预警”“设备健康”等每个栏目创建专属状态机。每个实例封装三样东西：当前状态（如 INIT → FETCHING → RENDERING → STANDBY → ERROR）、上下文指标（上次耗时、失败次数、数据量）、绑定的隔离线程池引用。栏目之间完全解耦，A 栏目进入 ERROR 不影响 B 栏目的 FETCHING。

• 状态转移携带可观测数据：FETCHING → RENDERING 时自动记录本次拉取耗时与返回条数
• STANDBY 持续超 30 秒，状态机主动调用 setCorePoolSize(2)，不依赖外部轮询
• ERROR 累计达阈值，触发降级动作——切换至熔断线程池（仅保留 2 个线程 + 内存队列）

状态变化直接驱动线程池行为

状态机不只是打标签，它定义了“状态 → 行为”的确定性映射：

• FETCHING 高频失败：发出事件，监听器上调核心线程数至 8，并切换队列为可扩容队列
• RENDERING 完成：触发清理逻辑，先 purge() 回收空闲 Worker，再安全下调核心线程数
• 从 STANDBY 切回 FETCHING：自动预热，提前拉起 1–2 个线程，避免冷启动延迟

缩放必须平滑、可控、可观测

线程数调整不是跳变，而是按业务节奏分步进行：

• 每次 resize 最多 ±2 个线程，两次操作间隔 ≥5 秒，防上下文切换风暴
• 扩容前检查系统负载：若 load average / CPU核数 > 0.7，暂停扩容，改走告警路径
• 所有调整记录结构化日志，含栏目名、原值、新值、触发状态、时间戳，便于回溯分析

与业务代码零侵入融合

通过注解（如 @DashboardState(column="pending", state="SUBMITTED")）声明方法允许执行的状态上下文，AOP 拦截器自动校验并注入对应栏目的状态机实例：

• 方法执行前：反射提取注解，确认当前栏目状态是否合法
• 方法执行后：根据返回结果或异常类型，驱动状态机转入下一状态（如成功→RENDERING，超时→ERROR）
• 业务方法只专注数据获取或渲染，线程资源由状态流转静默调度