bio是同步阻塞i/o模型，线程发起read/write后须等待内核完成数据准备与拷贝才继续执行，期间全程挂起；底层映射为recvfrom()等阻塞系统调用，服务端“一连接一线程”导致高并发下资源耗尽。
Java标准IO（即BIO）的同步阻塞模型，本质是线程发起读写操作后，必须等内核把数据准备好并拷贝到用户空间才继续执行，期间线程全程挂起、无法做其他事。这背后直接映射到操作系统级的系统调用，比如 recvfrom() 或 read()，不是Java自己造的逻辑，而是对底层机制的封装。
同步阻塞在两个阶段都“卡住”
BIO的“同步+阻塞”体现在IO操作的两个关键环节：
-
数据准备阶段：比如Socket读取时，内核接收缓冲区还没收到完整数据包，线程就停在
InputStream.read()这里，不返回也不释放CPU - 数据拷贝阶段：即使网络数据已到内核缓冲区，内核仍需把数据从内核空间复制到用户缓冲区（如byte[]），这个拷贝过程完成前，线程依然阻塞
底层对应的是系统调用的阻塞语义
Java的 Socket.getInputStream().read() 最终会触发Linux的 recvfrom() 系统调用。该调用默认行为就是阻塞式：
- 若缓冲区为空，进程立即进入不可中断睡眠状态（
TASK_UNINTERRUPTIBLE） - 直到网卡中断触发协议栈处理、数据入队、且拷贝完成，内核才唤醒该线程
- 整个过程由操作系统内核调度控制，JVM线程只是被动等待
一个连接一个线程，暴露资源瓶颈
服务端用BIO时，通常采用“accept一个连接→启一个线程→线程里持续read/write”的模式：
- 每个线程独占约8MB栈空间，1000并发≈8GB内存开销
- CPU核心数远少于线程数时，频繁上下文切换拖慢整体吞吐
- 哪怕99%的连接空闲、只等少量数据，线程也一直被占着——资源利用率极低
为什么开发中还能见到BIO
它没被淘汰，是因为在某些场景下够用且更简单：
- 内部工具类、脚本或管理后台，QPS很低（比如每天几百请求）
- 需要稳定长连接、协议简单（如心跳+固定报文头），不追求高并发
- 调试阶段：同步流程清晰，堆栈直观，出问题容易定位
- 某些低延迟敏感场景（如金融小批量订单），避免NIO状态机开销，BIO反而响应更快
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
