前言
 
网络通信是Java后端开发的底层基石，不管是日常开发用到的HTTP接口调用、RPC远程调用、Redis/Mysql网络连接、消息队列通信，底层全部依赖Java网络IO模型。
 
绝大多数开发者只会调用框架封装好的网络接口，却不懂底层通信逻辑：
 
- 为什么BIO并发量极低，无法支撑高并发场景？
- NIO三大核心组件Buffer/Channel/Selector到底如何配合工作？
- 同步阻塞、同步非阻塞、异步IO本质区别是什么？
- Netty为什么要基于NIO封装，而不用原生AIO？
- 线上高并发网络请求，到底该选择哪种IO模型？
 
本文面向有Java基础、备战面试、做网络服务开发的后端开发者，全程无入门废话，循序渐进讲解Java三大IO模型，附带可直接运行的服务端+客户端完整源码，拆解底层阻塞逻辑、梳理面试高频题、给出真实生产环境选型方案，彻底搞懂Java网络通信底层。
 
一、前置基础：网络IO的核心流程
 
一次完整的网络数据传输，分为两个阶段，所有IO模型的差异，都体现在这两个阶段的阻塞状态：
 
1. 等待数据就绪：客户端发送数据，服务端等待操作系统内核接收数据，从网卡拷贝到内核缓冲区；
2. 数据拷贝至用户态：将内核缓冲区的数据，拷贝到应用程序的用户进程缓冲区。
 
四个核心IO模型定义（先厘清概念，避免面试混淆）
 
- 阻塞：进程发起IO请求后，一直等待，什么事都不做；
- 非阻塞：进程发起IO请求后，立刻返回结果，没数据就轮询重试；
- 同步：进程主动等待IO结果，全程需要自身参与IO读写；
- 异步：进程发起IO请求后直接返回，IO完成后操作系统主动回调通知进程。
 
二、Java BIO：同步阻塞IO（传统阻塞通信）
 
2.1 核心原理
 
BIO是Java最基础的网络通信模型，同步+阻塞。
服务端每收到一个客户端连接，就需要单独开启一个线程处理读写请求；
线程在等待客户端数据、读写数据两个阶段都会全程阻塞，线程无法处理其他任务。
 
2.2 执行流程
 
1. 服务端创建 ServerSocket 绑定端口，监听客户端连接；
2. 调用 accept() 阻塞等待客户端连接，无连接时线程一直卡死；
3. 连接成功后，新建线程单独处理该客户端的读写；
4. 调用 read() 阻塞读取客户端数据，无数据时线程持续阻塞。
 
2.3 完整可运行源码
 
服务端代码
 
 
 
客户端代码
 
 
 
2.4 BIO致命缺点
 
1. 线程资源耗尽：1万条客户端连接就需要1万个线程，操作系统线程数有限，高并发下直接OOM；
2. 线程大量空闲阻塞：大部分连接无数据传输，线程依旧被占用，资源浪费极其严重；
3. 无法适配海量长连接：完全不适合网关、IM、消息推送这类长连接高并发场景。
 
2.5 适用场景
 
并发量极小、短连接、内网简单通信场景，现在生产环境基本淘汰。
 
三、Java NIO：同步非阻塞IO（Java网络核心，Netty底层）
 
3.1 核心原理
 
NIO全称New IO / Non-blocking IO，同步+非阻塞，JDK1.4推出，彻底解决BIO一线程一连接的痛点。
NIO不再为每个连接分配独立线程，一个线程可以管理成千上万个客户端连接，依靠多路复用器实现线程复用，也是目前Java网络编程主流底层。
 
3.2 NIO三大核心组件（面试必问）
 
1. Channel（通道）：双向读写数据，替代BIO单向的Stream流，支持异步读写；
2. Buffer（缓冲区）：所有数据必须先写入缓冲区，再通过通道传输，面向缓冲区编程；
3. Selector（多路复用选择器）：NIO核心，单线程轮询监听所有Channel的读写、连接事件，线程不会阻塞在单个连接上。
 
3.3 执行流程
 
1. 服务端开启ServerSocketChannel，绑定端口并设置为非阻塞模式；
2. 将通道注册到Selector多路复用器，监听连接、读、写事件；
3. Selector单线程轮询所有注册的通道，只处理就绪状态的事件；
4. 没有就绪事件时，线程阻塞在selector.select()，不会空轮询浪费CPU。
 
3.4 完整NIO服务端源码（单线程多路复用）
 
 
 
3.5 NIO优缺点
 
✅ 优点：
 
1. 单线程管理海量连接，极大减少线程开销，支持十万级长连接；
2. 非阻塞模式，线程不会被单个空闲连接阻塞；
3. 缓冲区+通道设计，读写效率远高于BIO流。
 
❌ 缺点：
 
1. 原生NIO API极其繁琐，需要手动处理事件轮询、缓冲区读写、粘包拆包；
2. 存在空轮询bug：selector.select()无故返回0，导致CPU100%飙升；
3. 依旧是同步IO，数据拷贝阶段需要用户线程主动参与。
 
3.6 适用场景
 
高并发长连接场景：RPC框架、网关、IM聊天、Netty框架底层，企业90%网络服务均使用NIO。
 
四、Java AIO：异步非阻塞IO（NIO2.0）
 
4.1 核心原理
 
AIO全称Asynchronous IO，异步+非阻塞，JDK1.7推出，真正意义上的异步IO。
用户线程发起IO请求后直接返回，无需等待，操作系统完成数据就绪+数据拷贝后，主动回调用户线程处理结果，全程用户线程不参与IO等待。
 
4.2 核心特点
 
1. 无需Selector多路复用器，操作系统内核全权监听IO事件；
2. 读写全程异步，线程彻底解放，性能理论最优；
3. 通过异步回调函数处理读写结果。
 
4.3 为什么Netty不使用AIO？
 
面试高频考点，核心3个原因：
 
1. 操作系统支持差：Windows对AIO支持完善，Linux内核AIO实现极其简陋，生产环境大多部署Linux；
2. 使用场景受限：异步回调编程复杂度极高，代码可读性差，回调地狱难以维护；
3. NIO足够够用：基于NIO封装的Netty，通过Reactor模式已经可以支撑百万级并发，AIO性能提升微乎其微。
 
4.4 适用场景
 
Windows系统下的高并发网络服务，Java后端Linux生产环境几乎不用。
 
五、三大IO模型全方位对比（面试直接背）
 
IO模型 阻塞类型 线程模型 并发能力 编程难度 生产使用场景 
BIO 同步阻塞 一线程一连接 低 简单 内网低并发短连接 
NIO 同步非阻塞 单线程多路复用 极高 复杂 网关、RPC、IM、Netty 
AIO 异步非阻塞 无需用户线程等待 最高 极难 Windows专属场景，极少使用 
 
六、网络通信高频面试题总结
 
1. BIO和NIO最大区别？
答：BIO一线程一连接，全程阻塞；NIO单线程管理多连接，非阻塞，基于多路复用器实现线程复用。
2. NIO Buffer的flip()方法作用？
答：切换读写模式，将position重置为0，limit设置为原position，从写模式切换为读模式。
3. 什么是IO多路复用？
答：一个线程通过Selector监听多个通道IO事件，只处理就绪事件，实现单线程管理多连接，减少线程上下文切换开销。
4. 为什么原生Java NIO没人直接用，都用Netty？
答：原生NIO需要手动处理粘包拆包、空轮询bug、断线重连、异常捕获，Netty封装了以上所有痛点，简化网络编程。
 
七、生产环境最终选型建议
 
1. 低并发、简单内网通信：无需纠结，简单BIO即可，开发成本最低；
2. 互联网高并发、长连接、RPC、网关：首选Netty（基于NIO），行业标准方案；
3. Linux服务器：直接放弃AIO，内核支持不足，无实际使用价值；
4. 短连接HTTP接口：SpringBoot底层已经封装好网络通信，无需手动操作IO模型。
 
结语
 
Java网络通信的核心本质，就是解决线程阻塞和并发连接之间的矛盾。
从BIO的低效线程阻塞，到NIO多路复用线程复用，再到AIO系统级异步回调，IO模型的迭代就是不断解放线程、提升并发能力的过程。
 
日常开发我们很少手写原生NIO，但弄懂底层IO模型，才能看懂Netty、RPC、消息队列的底层设计，应对面试和底层问题才能游刃有余。
 
后续会更新Netty核心源码、Reactor三大线程模型、TCP粘包拆包解决方案，感兴趣可以持续关注。