bio“一连接一线程”模型在高并发下必然崩溃，因线程栈内存线性暴涨、上下文切换频繁、os线程数受限（如1024）、文件描述符泄漏，且阻塞i/o导致线程长期闲置无法复用。
Java中BIO模型采用“每个连接一个线程”（Thread-Per-Connection）的设计，表面看逻辑清晰、开发简单，但深入底层就会发现它存在几个难以绕开的硬伤。
线程资源消耗呈线性爆炸式增长
每个Socket连接至少绑定一个独立线程，而每个Java线程默认占用约1MB栈空间。当并发连接达1万时，仅线程栈就需约10GB内存；达10万时直接突破百GB——远超常规服务器承载能力。操作系统层面的线程调度器也会因线程数过多陷入高频上下文切换，CPU大量时间花在保存/恢复寄存器状态上，而非真正处理业务。
- 线程创建本身有开销：JVM需分配栈、初始化Thread对象、注册到线程调度系统
- 线程空闲不释放：即使客户端只连不发数据，线程仍持续驻留并被调度器轮询
- 线程池只能缓解、无法根治：即便用固定大小线程池，连接数超限时请求会被拒绝或排队，丧失响应能力
阻塞调用导致线程长期“假运行”
accept() 和 read() 这两个核心操作均属系统调用，一旦数据未就绪，内核会将线程置为 WAITING 状态。但JVM线程快照（如 jstack）中常显示为 RUNNABLE ——因为它正执行 native 方法，实际却卡在内核态等待网络数据。这种状态极易误导排查：CPU使用率低、线程数飙升、服务无响应，三者并存就是典型BIO阻塞征兆。
- socket.read() 在无数据时挂起，线程无法复用去做其他事
- 未设置 setSoTimeout() 时，一次网络抖动或对端异常断连，线程可能永久阻塞
- 线程堆栈停留在 socketRead0/Native Method，掩盖真实瓶颈点
连接管理粗放，易引发泄漏与雪崩
BIO模型下连接生命周期完全由开发者手动控制，缺少统一收口机制。常见疏漏包括：异常路径未关闭 Socket、输入输出流未正确 try-with-resources、连接超时后未主动中断线程等。一个连接泄漏，就等于一个线程+对应内存+文件描述符永久占用。
- 忘记关闭 Socket 导致 fd 耗尽，后续 accept() 直接失败（IOException: Too many open files）
- 读写超时缺失，使线程在慢连接或恶意连接上无限期等待
- 没有心跳或空闲检测，僵死连接长期霸占线程，拖垮整个服务
无法适配现代高并发、长连接场景
BIO天然适合短连接、低频交互（如传统HTTP/1.0），但在IM、实时推送、物联网设备长连等场景中完全失效。这类业务往往连接数远大于请求数：一个客户端建连后维持数小时，期间仅偶发少量消息。BIO为每个长连接独占线程，等于为“沉默大多数”持续付费，资源利用率极低。
- 连接数与QPS脱钩：10万个连接 ≠ 10万QPS，但BIO仍要配10万个线程
- 无法做连接复用：每个线程绑定单一Socket，不能像NIO那样单线程轮询千个连接
- 缺乏事件驱动能力：无法感知“连接就绪”“可读”“可写”，只能被动轮询或阻塞等待
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
