java nio本身不提供分片上传与断点续传功能，需结合http范围请求、服务端进度持久化（如redis/数据库）、客户端校验（md5/fileid）及filechannel精确读写（offset+length）协同实现。
Java NIO 本身不直接提供“分片上传”或“断点续传”功能，它只是提供了非阻塞 I/O、通道（Channel）、缓冲区（Buffer）和选择器（Selector）等底层能力。真正实现大文件分片上传与断点续传，需要在 NIO 基础上结合 HTTP 协议规范（如 RFC 7233 支持范围请求）、服务端协作、客户端状态管理以及本地文件读写控制来完成。
分片上传：基于 NIO 的高效文件切片读取
核心是避免将整个大文件一次性加载进内存，而是用 FileChannel 配合 MappedByteBuffer 或分段 ByteBuffer 读取指定偏移量的数据块：
- 使用
RandomAccessFile.getChannel()获取可定位的FileChannel - 按固定大小（如 2MB/片）计算每一片的起始 offset 和 length
- 调用
channel.read(buffer, offset)精确读取某一片数据，无需移动文件指针 - 将读出的
ByteBuffer封装为 HTTP 请求体（如 multipart/form-data 的 part），带上分片序号、总片数、文件唯一标识（如 MD5 或 UUID）等元信息
断点续传：依赖服务端记录 + 客户端校验与续读
断点续传不是单靠 NIO 实现的，而是客户端和服务端约定一套状态同步机制：
- 客户端上传前先向服务端发起查询请求（如
GET /upload/status?fileId=xxx），获取已成功上传的分片列表或已接收字节数 - 服务端需持久化上传进度（如存入 Redis 或数据库），字段至少包括：
fileId、uploadedSize、completedChunks - 客户端根据返回结果跳过已传分片，从第一个未完成位置开始继续调用 NIO 读取并上传
- 关键细节：每次上传请求应携带
Content-Range头（如bytes 2097152-4194303/10485760），服务端据此校验并追加写入临时文件
服务端接收：用 NIO 高效落盘 + 范围写入
服务端收到分片后，不能简单追加到文件末尾（可能乱序），而要用随机写入方式拼接：
- 用
RandomAccessFile打开临时文件，获取getChannel() - 解析请求头中的
Content-Range，提取start字节偏移 - 调用
channel.write(buffer, start)直接写入对应位置（NIO 支持带 offset 的写入） - 所有分片收齐后，校验文件整体 MD5，再将临时文件重命名为正式文件
健壮性补充：必须做的几件事
仅靠 NIO 读写远远不够，实际落地还需考虑这些环节：
- 唯一文件标识：前端生成文件 hash（如 SparkMD5）作为 fileId，避免同名覆盖或重复上传
- 分片去重与幂等：服务端对每个分片做 hash 校验，相同内容只存一份，响应 200 并跳过写入
- 超时与重试：客户端需记录每片上传时间，失败后自动重试（建议指数退避），服务端清理超时未完成的上传任务
-
内存控制：避免用
MappedByteBuffer映射超大文件（易 OOM 或系统限制），优先选用分段ByteBuffer.allocateDirect()+channel.read(buffer, offset)
本质上，NIO 是让分片读写更高效、更可控的工具，但整个断点续传流程是前后端协同的协议设计问题。Spring Boot 可配合 @RequestBody + InputStream 接收分片，Netty 则能更深度利用 NIO 特性做高性能接收。关键不在“用了 NIO”，而在“如何用 NIO 精确控制读写位置 + 配合 HTTP 范围语义 + 持久化进度状态”。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
