面向对象状态机实现栏目级线程数自适应：每个栏目为独立状态机对象，封装状态、上下文与线程池，按状态流转（如FETCHING→RENDERING→STANDBY→ERROR）自动调控线程数，支持熔断、预热、渐进缩放及AOP无侵入集成。
在多栏目看板数据交互中，用面向对象状态机实现线程数自适应，核心是把“栏目”作为独立状态实体，让每个栏目的生命周期（如加载、渲染、空闲、异常）直接驱动其专属线程池参数调整，而不是靠全局阈值或定时轮询。
每个栏目封装为一个状态机对象
不共用一个状态机实例，而是为“实时订单”“库存预警”“设备健康”等每个栏目创建独立的状态机对象。每个对象持有自己的状态（INIT → FETCHING → RENDERING → STANDBY → ERROR）、上下文数据（上次耗时、失败次数、数据量）和绑定的线程池引用。这样，栏目之间互不影响，状态变更只作用于自身资源。
- 状态转移携带指标：比如 FETCHING → RENDERING 时，自动记录本次拉取耗时与返回条数，供后续缩放决策使用
- ERROR 状态累计达阈值，自动触发降级动作——切换至熔断线程池（仅保留 2 个线程 + 内存队列），不波及其他栏目
- STANDBY 持续超 30 秒，状态机主动调用 pool.setCorePoolSize(2)，而非等待外部调度器扫描
状态变化即线程池指令
状态机不只做标记，而是定义“状态 → 行为”的映射规则。例如：
- FETCHING 高频失败：状态机发出事件，监听器调用 setCorePoolSize(8) 并切换队列为可扩容队列
- RENDERING 完成：触发清理逻辑，调用 purge() 回收空闲 Worker，再安全下调核心线程数
- 从 STANDBY 切回 FETCHING：预热动作自动启动，提前拉起 1–2 个线程，避免冷启动延迟
缩放过程必须可控、渐进、可观测
线程数不是跳变，而是按状态节奏分步调节：
- 每次 resize 最多 ±2 个线程，两次操作间隔 ≥5 秒，防止上下文切换风暴
- 扩容前检查系统负载：若 load average / CPU核数 > 0.7，暂停扩容，改走告警路径
- 所有调整操作记录结构化日志，含栏目名、原值、新值、触发状态、时间戳，便于回溯分析
与业务代码自然融合，不侵入逻辑
通过注解（如 @DashboardState(column="pending", state="SUBMITTED")）声明方法允许执行的状态上下文，AOP 拦截器自动校验并注入状态机实例。业务方法只需专注数据获取或渲染，线程资源由状态流转静默调度。
- 方法执行前：拦截器反射提取注解，确认当前栏目状态是否合法
- 方法执行后：根据返回结果或异常类型，驱动状态机转入下一状态（如成功→RENDERING，超时→ERROR）
- 状态跃迁自动触发线程池参数更新，开发者无需手动调用 setCorePoolSize
