多栏目看板线程数自适应需为每个栏目构建轻量IO状态机，将IDLE→CONNECTING→WAITING_IO→RECEIVING→ERROR_BURST等状态及可观测IO指标（如首包延迟、错误码）直接映射为线程池参数调整，通过注解+AOP实现零侵入驱动，确保伸缩平滑可控、可观测可回溯。
在多栏目高并发看板场景中，线程数自适应不能靠全局统调，而要让每个栏目“感知自身io节奏”，用io状态机驱动资源伸缩——本质是把网络/数据源的就绪状态、响应延迟、失败模式等io行为特征，直接映射为线程池参数的确定性调整。
IO状态机不是额外加的状态管理框架，而是对栏目IO生命周期的精准建模
每个栏目（如“实时订单”“设备告警”）对应一个轻量IO状态机，状态定义紧贴真实IO行为：
-
IDLE→ 无请求，线程保底为2，keepAliveTime设为5分钟 -
CONNECTING→ 建连中，预热1个线程，启用连接超时熔断（3s） -
WAITING_IO→ 已发请求、等待响应（如HTTP等待Socket就绪），不增线程，但记录RTT与超时次数 -
RECEIVING→ 数据流持续到达（如SSE长连接、WebSocket帧接收），自动扩容至核心线程6～8，切换为无界缓冲队列 -
ERROR_BURST→ 连续2次IO超时或连接拒绝，立即降级：切换至熔断线程池（仅2线程 + 内存队列），并上报下游服务异常信号
状态跃迁必须携带IO可观测数据：
-
WAITING_IO → RECEIVING时，附带本次首包延迟（first-byte latency）和接收速率（bytes/sec） -
RECEIVING → IDLE时，统计本次会话总耗时、丢包标记、是否触发重传 -
ERROR_BURST触发时，带上错误码（如ECONNREFUSED/ETIMEDOUT）、上游服务域名、重试次数
线程池参数由IO事件实时驱动，而非定时轮询或阈值硬编码
不同IO特征栏目绑定差异化线程池模板，状态变更直接触发其行为：
- HTTP轮询类（库存同步）→
IoBoundPool：核心线程=4，最大=32；状态进WAITING_IO时延长keepAliveTime至90秒，防频繁启停 - WebSocket推送类（实时订单）→
StreamAwarePool：支持动态扩缩；RECEIVING状态每秒吞吐＞5KB时，+1线程（上限+4），间隔≥3秒 - 文件拉取类（日志快照）→
BulkIoPool：固定核心=CPU核数×1.5；仅在RECEIVING且缓冲区填充率＞80%时，临时提升最大线程数
所有调整动作内置平滑约束：
- 单次线程数变动 ≤ ±2
- 两次resize间隔 ≥ 5秒
- 扩容前检查系统load：若
load / CPU核数 > 0.7，跳过扩容，改发io_backpressure_alert事件 - 缩容只清理空闲Worker：先
purge()，再setCorePoolSize()，绝不中断正在处理的IO回调
IO状态机与业务代码零耦合，靠拦截与反射自动注入
用注解声明IO语义约束：
@IoState(column = "order", phase = "RECEIVING", timeout = 1500)
public List<Order> fetchRealtimeOrders() { ... }AOP拦截器自动完成三件事：
- 方法执行前：校验当前栏目是否处于允许的IO状态，否则拒绝执行
- 方法返回后：根据HTTP状态码、异常类型、耗时，驱动状态机转入下一态（如
404 → ERROR_BURST，200+耗时<200ms → IDLE） - 异步回调（如Netty ChannelRead）中，通过
Channel.attr()绑定状态机实例，IO事件直接触发状态流转
这样，线程资源调度就不再依赖人工经验或粗粒度监控指标，而是由每个栏目的真实IO脉搏决定——连不上就少占线程，收得快就多配资源，出错了就快速隔离。整个过程可观测、可回溯、无抖动。
