Java NIO高性能文件服务器核心在于零拷贝（transferTo/transferFrom）、单线程多路复用（Selector+非阻塞SocketChannel）、DirectBuffer池化复用及轻量二进制协议设计，避开用户态与内核态反复拷贝，显著降低CPU和内存开销。
Java NIO 实现高性能文件服务器，核心不在“写得多”，而在“绕得巧”——避开内核态与用户态反复拷贝、减少线程调度开销、用好操作系统原生能力。关键不是堆代码，而是选对组件、理清协作逻辑、守住几个关键点。
零拷贝传输大文件：用 transferTo/transferFrom 替代传统读写
传统 FileInputStream + FileOutputStream 每次 read/write 都触发系统调用，数据在用户缓冲区和内核缓冲区之间来回搬动，GB 级文件可能产生数十万次拷贝。NIO 的 FileChannel 提供真正的零拷贝路径：
- 服务端下载时，直接 FileChannel.transferTo(0, file.length(), socketChannel)：数据从文件系统页缓存直达网卡 DMA 缓冲区，全程不经过 JVM 堆内存
- 客户端上传时，用 socketChannel.read(byteBuffer) 接收元数据（如文件名、大小），再用 FileChannel.transferFrom(socketChannel, 0, fileSize) 将网络数据流直写磁盘
- 注意：transferTo 在 Linux 上底层调用 sendfile()，要求源通道是 FileChannel、目标通道是 WritableByteChannel（如 SocketChannel）；Windows 下部分场景会退化为普通拷贝，但性能仍优于流式 API
单线程多路复用管理海量连接：Selector + 非阻塞 SocketChannel
一个 Selector 实例可监听成千上万个 SocketChannel 的就绪事件，避免 BIO 模式下“1 连接 = 1 线程”的资源爆炸：
- ServerSocketChannel 设为非阻塞，并注册 OP_ACCEPT；收到新连接后，立即将对应的 SocketChannel 设为非阻塞并注册 OP_READ
- 读取时只处理“已就绪”的通道，不会卡在某一个慢连接上；写入采用“边写边注册 OP_WRITE”，写完立即取消，防止空轮询
- 实际项目中建议搭配连接数限流（如限制同时活跃上传连接 ≤200）、空闲连接超时关闭（如 30 秒无读写自动断开），防止资源耗尽
缓冲区高效复用：避免频繁分配堆外内存
ByteBuffer.allocateDirect() 虽快但创建成本高，高频小包传输易引发 GC 或内存碎片：
立即学习“Java免费学习笔记（深入）”；
- 使用对象池管理 DirectBuffer，例如用 ConcurrentLinkedDeque 缓存固定尺寸（如 64KB）的 ByteBuffer，acquire 时优先复用，超出阈值才新建
- 协议头（如命令字、文件名长度）用小缓冲区（4–16 字节）单独处理；文件体传输则跳过 Buffer，走 transfer 系列方法，彻底规避用户态缓冲
- 切忌在 handler 中长期持有 ByteBuffer 引用，尤其不能跨事件循环保存 position/limit 状态，否则下次读写会错乱
协议设计轻量且可控：自定义二进制头 + 断点续传支持
高性能不只靠底层，也依赖简洁可靠的通信契约：
- 每个请求以 16 字节定长头开始：4 字节命令码（UPLOAD=0x01, DOWNLOAD=0x02）、8 字节文件大小、4 字节校验 CRC32，后续紧跟文件名 UTF-8 字节数组和原始内容
- 上传支持分块接收：客户端按 1MB 切片发送，服务端记录每个文件的已接收偏移量（ConcurrentHashMap<String, AtomicLong>），崩溃恢复时只需续传剩余部分
- 进度监控用独立线程定时扫描状态表，通过 HTTP 端点或 JMX 暴露，不干扰主 IO 线程
