BIO模型采用“一个连接一个线程”方式，导致内存线性暴涨（如10万连接需100GB栈内存）和上下文切换失控（数万线程争抢数十核），I/O阻塞时线程仍独占资源，线程池无法根治该结构性缺陷。
“一个连接一个线程”是传统 BIO（Blocking I/O）模型的典型实现方式，直观易懂，但在海量长连接场景下会迅速暴露两大硬伤：内存爆炸性增长和上下文切换失控。这不是配置调优能解决的问题，而是模型本身的结构性缺陷。
内存开销呈线性堆叠，1MB/线程很快见底
每个 Java 平台线程默认分配约 1MB 的栈空间，且由操作系统独占、不可复用。当设备连接数从几千升至百万级：
- 10,000 连接 ≈ 占用 10GB 栈内存（仅线程栈，不含堆对象）
- 100,000 连接 ≈ 至少 100GB 内存需求，远超常规服务器物理上限
- 线程栈全部驻留于本地内存（native memory），不受 JVM 堆 GC 管理，泄漏风险高且难以监控
上下文切换频次远超 CPU 承载能力
现代服务器常见 16–64 核，但 BIO 模型常需启动数万线程来维持长连接。此时操作系统调度器被迫高频切片：
- 假设 50,000 线程争抢 32 个逻辑核，平均每个核需轮转 1500+ 线程
- 每次切换需保存/恢复寄存器、程序计数器、内核栈等，消耗数百纳秒到微秒级 CPU 时间
- 频繁切换导致 CPU 缓存（L1/L2）反复失效，实际执行业务代码的时间占比可能低于 10%，即所谓 “thrashing” 状态
I/O 阻塞进一步放大资源浪费
BIO 线程在等待网络读写时仍持续占用完整栈和调度配额：
- 一个 TCP 长连接若 99% 时间处于空闲等待状态，其对应线程却始终“在线”，白白消耗内存与调度权
- 线程无法被复用于处理其他就绪连接，导致 CPU 利用率低、吞吐上不去、延迟反而升高
- 连接突发增长时，线程创建本身触发系统调用（clone()），带来额外内核态开销，加剧响应抖动
这不是线程池能绕过的根本问题
固定大小线程池可缓解创建销毁开销，但无法改变“线程 = 连接”的绑定关系：
- 池中线程数仍受限于内存与调度压力，无法随连接数弹性伸缩
- 当活跃连接数超过池容量，新连接只能排队或被拒绝，失去长连接意义
- 池中空闲线程仍在消耗资源，而真正需要并发处理的只是少数 I/O 就绪事件
本质上，“一个连接一个线程”把 I/O 等待这种低开销行为，错误地映射为高开销的 OS 资源单元。破局关键在于解耦——让少量 OS 线程驱动大量连接事件，这正是 NIO + Reactor 或虚拟线程这类现代模型的设计原点。
