bio需多线程是因为accept()和read()均阻塞，单线程无法并发处理连接；通过主线程accept+线程池处理读写，实现连接与业务分离，但受限于线程数、栈内存及调度开销，高并发时应转向nio。
Java 中 BIO（Blocking I/O）模型本身是同步阻塞的，每个连接都需要一个独立线程来处理读写操作。它无法像 NIO 那样单线程管理多个连接，但可以通过多线程机制缓解并发连接带来的瓶颈——核心思路是“一个连接对应一个线程”，用线程池控制资源消耗，避免无限制创建线程导致系统崩溃。
为什么 BIO 需要多线程
BIO 的 socket.accept() 和 socket.getInputStream().read() 都会阻塞当前线程。如果只用单线程，服务器只能串行处理连接和请求，吞吐量极低。引入多线程后，主线程专注 accept 新连接，每个新连接交由工作线程处理，实现连接接收与业务处理的分离。
- 主线程不被 I/O 阻塞，能持续接受新连接
- 每个客户端连接由独立线程处理，彼此隔离
- 配合线程池复用线程，避免频繁创建销毁开销
典型实现：主线程 + 固定线程池
不直接为每个连接 new Thread()，而是使用 ExecutorService 管理有限数量的工作线程：
- ServerSocket 启动后，在 while 循环中调用 accept() 获取 Socket
- 每次获取到新 Socket，提交给线程池执行 Runnable 任务
- Runnable 内部完成输入流读取、业务逻辑、输出流写回、socket 关闭
- 线程池大小需权衡：太小会导致请求排队；太大则引发上下文切换和内存压力
关键瓶颈与应对要点
多线程 BIO 并不能消除 BIO 的本质缺陷，只是在可接受范围内提升并发能力。实际部署时需注意：
- 连接数上限受线程数硬约束，例如 200 个线程最多同时处理 200 个活跃连接
- 每个线程独占栈空间（默认 1MB），高并发下易触发 OOM
- 大量线程 sleep/wait 时，操作系统调度开销显著上升
- 必须显式关闭 socket 和流，否则连接泄漏会快速耗尽文件描述符
什么时候该考虑替代方案
当连接数稳定超过几百、或存在大量长连接/空闲连接时，多线程 BIO 已接近极限。此时应评估升级路径：
- 改用 Java NIO（Selector + Channel + Buffer），单线程可支撑数千连接
- 采用 Netty 等封装良好的异步框架，屏蔽底层复杂性
- 对 HTTP 场景，可选用 Tomcat（支持 BIO/NIO/APR 切换）或 Undertow
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
