Java实现文件分片上传案例

wen java案例 2026-08-04 2

Java实现文件分片上传案例：从原理到实战的完整指南

目录导读

为什么需要文件分片上传？ —— 突破大小限制与网络瓶颈
分片上传的核心流程 —— 前端切片、后端合并、断点续传
Java后端核心代码实现 —— Spring Boot + MultipartFile 实战
分片上传的并发与一致性处理 —— 防止数据错乱
常见问题FAQ —— 面试与实战高频疑问解答
性能优化与最佳实践 —— 内存、IO、校验策略

为什么需要文件分片上传？

在传统上传方式中，一个大文件（如1GB视频）直接通过HTTP请求发送，会面临三个致命问题：

Java实现文件分片上传案例

超时风险：网络波动导致连接中断，整体失败。
内存溢出：服务端一次加载整个文件到内存，容易OOM。
无法断点续传：失败后必须从头开始。

分片上传（Chunked Upload） 的核心思想是：将一个大文件切割为多个小块（如每块5MB），逐个上传，每个分片独立成功，全部上传后服务端合并成完整文件,这能显著提升成功率与用户体验。

分片上传的核心流程设计

一个标准的实现通常包含以下角色与步骤：

前端（Web/客户端）
- 计算文件唯一标识（如MD5）
- 按固定大小切片（例如5MB）
- 并发或串行上传每个分片（携带identifier和chunkIndex）
- 所有分片完成后，通知服务端合并
后端（Java服务）
- 接收分片，保存到临时目录，文件名包含identifier + chunkIndex
- 维护一个分片上传记录（内存Map或数据库）
- 当所有分片齐了，触发合并，删除临时文件
断点续传

前端查询服务端已上传的分片索引，只上传缺失部分

Java后端核心代码实现（Spring Boot示例）

我们使用Spring Boot 2.x + MultipartFile来接收分片。

1 上传分片接口

@RestController
@RequestMapping("/upload")
public class ChunkUploadController {
    // 存储分片信息的临时目录
    private static final String CHUNK_DIR = "/data/chunks/";
    private static final String MERGED_DIR = "/data/files/";
    @PostMapping("/chunk")
    public ResponseEntity<String> uploadChunk(
            @RequestParam("file") MultipartFile file,
            @RequestParam("identifier") String identifier,
            @RequestParam("chunkIndex") int chunkIndex,
            @RequestParam("totalChunks") int totalChunks) throws IOException {
        // 创建该文件的专属分片目录
        File chunkFolder = new File(CHUNK_DIR + identifier);
        if (!chunkFolder.exists()) {
            chunkFolder.mkdirs();
        }
        // 保存分片文件
        File chunkFile = new File(chunkFolder, String.valueOf(chunkIndex));
        file.transferTo(chunkFile);
        // 简单校验：是否所有分片都上传完成
        if (checkAllChunksUploaded(chunkFolder, totalChunks)) {
            mergeChunks(identifier, totalChunks);
        }
        return ResponseEntity.ok("chunk " + chunkIndex + " uploaded");
    }
    private boolean checkAllChunksUploaded(File chunkFolder, int totalChunks) {
        return chunkFolder.listFiles().length == totalChunks;
    }
}

2 合并分片方法

private void mergeChunks(String identifier, int totalChunks) throws IOException {
    File chunkFolder = new File(CHUNK_DIR + identifier);
    File mergedFile = new File(MERGED_DIR + identifier + ".ext"); // 实际后缀由前端传入
    try (FileOutputStream fos = new FileOutputStream(mergedFile)) {
        for (int i = 0; i < totalChunks; i++) {
            File chunk = new File(chunkFolder, String.valueOf(i));
            byte[] buffer = new byte[1024 * 1024]; // 1MB buffer
            int len;
            try (FileInputStream fis = new FileInputStream(chunk)) {
                while ((len = fis.read(buffer)) != -1) {
                    fos.write(buffer, 0, len);
                }
            }
            chunk.delete(); // 删除分片，释放空间
        }
    }
    chunkFolder.delete(); // 删除临时目录
}

注意：真实生产环境中，identifier建议使用MD5后的大文件哈希值,避免文件名冲突。

分片上传的并发与一致性处理

当多个分片同时上传时,必须确保以下两点：

分片不丢失：前端需保证每个分片上传成功后再发下一个，或接收端返回成功码。
合并顺序正确：合并时按chunkIndex升序写入。

常见方案：

使用Redis记录已上传分片索引（Set类型），支持快速判断缺失分片。
合并时加分布式锁（如Redisson），防止多个请求同时触发合并。
使用文件锁（FileChannel.lock()）在本地保证唯一合并线程。

常见问题FAQ

问：分片上传和断点续传是一回事吗？

答：不是，分片上传是传输策略，断点续传是失败恢复策略，断点续传依赖分片机制——已上传的分片不用重传,只需续传缺失部分。

问：Java中如何校验文件完整性？

答：推荐MD5或SHA-256，前端计算整个文件的哈希值，上传前连同identifier发送给后端，合并后，后端重新计算哈希并与前端比较,不一致则重传污染的分片。

问：分片大小应该如何设置？

答：经验值如下：

网络差（移动端）：1MB～2MB
一般以太网：5MB～10MB
内网高速环境：20MB～50MB
太碎片化会导致TCP连接过多；太大又失去分片意义。

问：并发数量限制多少合适？

答：浏览器一般限制同域名6个TCP连接，所以前端建议并发3～4个分片上传,后端用线程池控制服务端IO压力。

性能优化与最佳实践

使用流式读写：合并时不要用FileChannel.transferTo（虽快但占内存），建议用缓冲流逐块写入。
异步合并：合并大文件耗时，可放入MQ或线程池异步执行，前端轮询状态。
磁盘IO监控：大量分片同时写盘可能导致IO阻塞，可引入消息队列削峰。
清理机制：若用户放弃上传，临时分片会残留，用@Scheduled定时扫描超过24小时未合并的目录并删除。
前端优化：使用XMLHttpRequest或axios进行分片上传，并监听progress事件显示进度条。

扩展思考：

如果采用对象存储（OSS），可借助其原生MultipartUpload API，Java端只需管理分片元数据。
对超大文件（10GB+），建议使用内存映射文件（Memory-Mapped File）进行合并,避免频繁IO。

案例经过精简但保留了核心架构，适用于中小型业务，若需完整可运行源码，可参考开源项目如fastdfs-client或tus-java-client,它们已在生产环境验证过稳定性。