核心目标是避免阻塞、减少拷贝、并行处理、安全合并；分三步：前端切片并携带元信息，后端用FileChannel.transferFrom写独立临时文件，全量接收后单线程按序transferTo合并。
在文件上传业务中，用 NIO 通道配合多线程分片，核心目标是：避免阻塞、减少拷贝、并行处理、安全合并。这不是简单堆砌技术，而是围绕“大文件 + 高并发”场景做系统性设计。
分片上传的后端接收逻辑要分三步走
前端按固定大小（如 5MB）切片，并携带分片序号、总片数、唯一文件标识（如 file_id 或 md5 前缀）；后端不直接拼接原始流，而是：
- 为每个分片生成独立临时文件，命名含 file_id + chunk_index（例如
abc123_0002.tmp），存入专用临时目录 - 用 FileChannel.transferFrom() 接收每个分片数据——它适合从网络输入流（如
ServletInputStream包装成ReadableByteChannel）向本地文件写入，比传统流更少内存拷贝 - 收到全部分片后，触发合并任务：按序读取各
.tmp文件，用 transferTo() 追加写入最终文件（注意 position 控制），最后删除临时片
多线程不能无脑开，得按职责隔离
上传入口线程（如 Tomcat 工作线程）只负责解析请求、校验参数、分发分片任务；真正耗 I/O 的写入操作交给独立线程池，避免阻塞 Web 容器线程：
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
- 使用 ThreadPoolExecutor 管理写入线程，核心数建议设为 CPU 核数 × 1.5～2（I/O 密集型），拒绝策略用
CallerRunsPolicy防雪崩 - 每个分片任务封装为
Runnable，内部打开FileOutputStream获取FileChannel，调用transferFrom(srcChannel, 0, chunkSize)——注意srcChannel必须支持read()，可借助Channels.newChannel(inputStream) - 避免多个线程同时写同一文件：临时分片文件必须独立路径；最终合并阶段由单一线程串行执行，或通过
ConcurrentHashMap+computeIfAbsent控制 per-file 合并锁
NIO 通道的关键优化点
光用 FileChannel 不够，得选对方法和参数：
立即学习“Java免费学习笔记（深入）”；
-
优先用
transferFrom()而非transferTo()接收分片：因为源是网络流（不可 seek），transferTo()要求源 channel 支持 position 移动，而transferFrom()只需顺序读，更稳妥 - 对超大分片（>2GB），拆成多次
transferFrom()调用，每次传 ≤2GB，避免某些 JVM/Linux 内核限制 - 临时文件使用 DirectByteBuffer 辅助（如配合
AsynchronousFileChannel）可进一步降低 GC 压力，但普通同步写入中，transferFrom本身已绕过 JVM 堆，无需额外配置 - 合并时用
RandomAccessFile.getChannel().position(offset)定位，再transferTo()追加，确保顺序写入不覆盖
必须考虑的健壮性细节
生产环境不能只谈性能，还要扛住异常：
- 每个分片写入前检查磁盘空间，失败立即返回 507（Insufficient Storage）
- 用 FileLock 保护合并过程：获取独占锁后再读所有 .tmp 文件，防止合并中途新分片写入导致状态不一致
- 设置分片超时清理机制（如用
ScheduledExecutorService扫描 24 小时未完成的 file_id 目录并删除） - 上传进度可基于 Redis 记录
file_id:progress，前端轮询，比服务端维持长连接更轻量
