线程池不直接处理非阻塞i/o，而是作为业务逻辑执行层与事件驱动机制解耦协作：i/o线程仅负责轻量读写与分发，耗时操作（如db查询、json解析）必须卸载至独立业务线程池异步执行，避免阻塞事件循环。
线程池本身不直接处理非阻塞 I/O，它处理的是“任务”；而非阻塞 I/O 的核心在于事件驱动和回调触发。真正构建高性能响应式并发框架的关键，是把线程池作为**业务逻辑执行的承载层**，与非阻塞 I/O 的事件通知机制（如 ReadListener、Netty ChannelHandler、Reactor 的 Subscriber）解耦协作——I/O 线程只负责读写与分发，耗时逻辑交由独立线程池异步执行。
明确角色分工：I/O 线程 vs 业务线程池
高性能响应式框架必须避免让 I/O 线程执行数据库查询、JSON 解析、远程调用等耗时操作。否则会拖慢整个事件循环。
- I/O 线程（如 Netty 的 NioEventLoop、WebFlux 的 reactor-http-nio-*）：只做轻量工作——接收字节、触发 onRead、转发数据、写回响应头
- 业务线程池（如 ForkJoinPool.commonPool() 或自定义 ThreadPoolExecutor）：专门承接从 I/O 回调中卸载下来的重逻辑，例如 CompletableFuture.supplyAsync(..., businessPool)
- 典型场景：收到一个上传请求，I/O 线程通过 ReadListener 分块读取 body → 每块数据封装为 Mono.just(data) → flatMap 后提交到业务线程池做校验/压缩/落盘
用 CompletableFuture + 自定义线程池实现可回调的任务调度
CompletableFuture 是连接非阻塞 I/O 和线程池最自然的桥梁。它支持在任意线程上注册回调，且不阻塞上游 I/O 流。
- 不要用默认的 ForkJoinPool：它的并行度受 CPU 核心数限制，不适合 I/O 密集型任务；应创建专用线程池，例如 new ThreadPoolExecutor(20, 200, 60L, TimeUnit.SECONDS, new SynchronousQueue())
- 关键写法：supplyAsync(() -> doHeavyIO(), ioIntensivePool).thenApply(result -> transform(result)).thenAccept(finalRes -> writeResponse(finalRes))
- 异常要显式捕获：用 exceptionally() 或 handle() 处理失败路径，避免 silent drop；否则下游 Mono/Flux 可能中断而无日志
与 Servlet 3.1 非阻塞 I/O 集成的实操要点
若基于传统 Servlet 容器（如 Tomcat 9+），需手动启用非阻塞读，并将 ReadListener 与线程池联动。
- 在 Servlet 中调用 request.getInputStream().setReadListener(...)，确保容器开启非阻塞支持（web.xml 中
true ） - ReadListener.onDataAvailable() 中：用 ServletInputStream.read() 非阻塞读取可用字节，立即交由业务线程池处理，切勿在此方法内做同步等待或长耗时操作
- ReadListener.onAllDataRead() 表示 body 读完，此时可触发最终聚合逻辑；onError() 必须清理资源并通知上层（如发布 Mono.error）
- 注意：ReadListener 回调由容器 I/O 线程触发，因此所有耗时逻辑必须 offload 到线程池，否则会卡住整个连接复用队列
响应式框架（如 WebFlux）中线程池的隐式使用策略
WebFlux 默认使用 Reactor 的 elastic 或 boundedElastic 线程池处理阻塞调用，但生产环境需主动控制。
- 对阻塞操作（JDBC、旧版 SDK、文件写入），显式指定 Scheduler：Mono.fromCallable(() -> legacyDbCall()).subscribeOn(Schedulers.fromExecutor(customIoPool))
- 避免滥用 publishOn()：它会切换执行线程，带来上下文切换开销；仅在需要将结果交由特定线程（如 UI 线程、日志线程）时使用
- 监控线程池指标：通过 Micrometer 暴露 activeCount、queueSize、rejectedExecutionCount，及时发现过载或配置失当
