流程控制通过状态机驱动线程池动态调整：将栏目生命周期建模为init→fetching→rendering→standby→error五态，每态绑定资源语义与可观测指标，事件驱动策略监听器执行平滑缩放，内置节流防护避免抖动。
流程控制本身不直接调节线程数，但它是驱动线程资源动态调整的“决策中枢”——关键在于把栏目数据交互的完整生命周期（加载→拉取→渲染→空闲→异常）建模为可识别、可响应、可追踪的状态流转过程，并让每一步流转触发对应的线程池动作。
用状态流转替代硬编码调度
避免在代码里写“if (流量高) setCorePoolSize(16)”这类静态判断。改为定义清晰的栏目状态（如 INIT → FETCHING → RENDERING → STANDBY → ERROR），每个状态对应明确的资源语义：
- FETCHING：需保障并发拉取能力，自动启用中等核心线程数（如6～8），并绑定可扩容队列
- RENDERING：CPU密集型操作为主，收缩IO线程，释放资源给计算线程，同时记录本次耗时供后续缩放参考
- STANDBY：持续30秒无新请求，主动下调核心线程至保底值（如2），不依赖外部定时器扫描
- ERROR：连续失败3次，立即切换至熔断线程池（仅2线程+内存队列），隔离故障，不影响其他栏目
状态转移携带可观测指标
流程控制的价值不仅在于“走到哪”，更在于“为什么走到这”。每次状态跃迁都应附带上下文数据，作为线程数调整的依据：
- FETCHING → RENDERING 时，记录本次API平均RT、返回数据量、失败标记；若RT > 800ms，下一次FETCHING自动提升线程权重
- RENDERING → STANDBY 时，检查最近5次渲染耗时方差；若波动小，说明负载稳定，可更激进缩容
- ERROR 累计触发时，除降级外，还向监控系统发事件，用于关联分析下游服务健康度
流程与线程池解耦，通过事件通信
不在线程池对象内部写状态判断逻辑，而是由流程控制器（如状态机）在状态变更后发出标准化事件（如 “ColumnFetchSuccess”, “ColumnRenderComplete”），由独立的线程策略监听器响应：
- 监听到 “ColumnFetchSuccess” 且平均耗时下降 → 缓慢回调核心线程数（每次-1，间隔≥5秒）
- 监听到 “ColumnStandbyTimeout” → 触发 purge() 清理空闲Worker，再安全调用 setCorePoolSize(2)
- 监听到 “ColumnErrorBurst” → 切换线程池实现类，加载熔断配置，同时上报告警
保障缩放动作平滑可控
流程控制必须内置节流与防护机制，防止线程数抖动引发系统震荡：
- 单次 resize 幅度限制在 ±2 线程内，两次调整间隔不少于5秒
- 扩容前校验系统负载（load / CPU核数 > 0.7 时暂停扩容，转为堆积告警）
- 所有调整操作写入结构化日志，包含栏目名、原线程数、新线程数、触发状态、时间戳，便于回溯归因
