用io状态机实现栏目级线程数自适应，即每个栏目绑定独立状态机，依fetching→rendering→standby→error等状态流转及实时io指标（rt、失败率、缓存命中率）动态调优专属线程池，确保缩放平滑、互不干扰且带负载防护。
在多栏目看板数据交互中，用IO状态机实现线程数自适应，关键是把“栏目”作为独立IO行为单元，让每个栏目的网络拉取、缓存校验、结果渲染等IO阶段，驱动专属线程池的平滑伸缩——不是靠全局阈值硬调，而是让状态流转本身成为资源调度指令。
每个栏目绑定独立IO状态机实例
不复用一个状态机管理所有栏目。例如，“实时订单”“库存预警”“设备健康”三个栏目，各自初始化一个状态机对象，内部封装：
- 当前状态（INIT → FETCHING → RENDERING → STANDBY → ERROR）
- IO上下文指标（最近3次API平均RT、失败次数、响应体大小）
- 绑定的IO线程池引用（如ScalingDynamicPool）
这样，一个栏目因下游超时进入ERROR，只会触发自身熔断（切至2线程内存队列），不影响其他栏目正常并发拉取。
状态转移携带IO可观测信号
状态变化不是标记，而是携带真实IO反馈，作为线程数调整依据：
- FETCHING → RENDERING：记录本次HTTP耗时与body字节数；若平均RT > 800ms，下一轮FETCHING自动提升核心线程至8，并启用ResizableLinkedBlockingQueue
- RENDERING → STANDBY：检查本地缓存命中率；若连续5次>95%，说明IO压力低，安全下调核心线程至保底值2
- ERROR累计达3次/分钟：立即切换线程池实现类，启用熔断策略（仅2线程 + 无界内存队列），同时上报下游服务异常事件
IO型线程池按状态事件动态响应
针对IO密集特性，线程池不静态配置，而由状态机事件驱动参数变更：
- FETCHING状态激活时：调用setCorePoolSize(6)，并设置keepAliveTime=60秒，保障并发拉取能力
- STANDBY持续超30秒：触发purge()清理空闲Worker，再执行setCorePoolSize(2)，避免资源空转
- 从STANDBY切回FETCHING前：预热启动1–2个线程，防止冷启动导致首屏延迟升高
缩放过程强制平滑与防护
IO任务易受网络抖动影响，线程数调整必须防震荡：
- 单次resize幅度严格限制为±2线程，两次调整间隔≥5秒
- 扩容前校验系统负载：若load average / CPU核数 > 0.7，暂停扩容，改发告警并维持当前配置
- 所有操作记结构化日志：含栏目名、原线程数、新线程数、触发状态、时间戳，便于定位IO毛刺根因
