Java 服务上传大文件怎么选对象存储分片：内存、带宽与失败重试

Java 服务上传大文件时，最容易踩的坑不是 API 不会调用，而是把内存、连接并发和失败重试混成一个参数。更稳妥的做法是先确定文件大小与可接受的等待时间，再选择是否使用对象存储的 multipart 流程，让失败只影响某一个分片。

文件较大、网络波动明显或希望并行传输时，优先采用异步 multipart；分片大小与并发度要按内存预算和出口带宽一起定，上传失败则清理未完成的 upload。

先把上传负载拆成三个约束

对象存储的 multipart 不是“把文件切几刀”这么简单。Java 服务至少要同时看三件事：单片大小决定内存和重试成本，并发数决定连接与出口压力，完成与中止决定临时数据会不会长期残留。

下面的示例采用 AWS SDK for Java 2.x 的真实类型名。官方文档同时提供了同步客户端、Java 异步客户端和 CRT 客户端；异步客户端启用 multipart 后，可以让大对象传输走并行路径。文章中的 8 MB、16 MB 只是起步建议，不能直接当成所有业务的固定阈值。

按文件大小和出口带宽选择方案

文件不大，先保持单次上传

头像、短音频和几十 MB 以内的普通附件，如果服务已经有明确的请求体上限、超时和校验逻辑，可以先使用单次 PutObject。此时主要目标是让路径简单，避免为了“云上最佳实践”额外引入 uploadId、分片列表和清理任务。

文件变大后，分片大小决定重试账单

假设一个 1 GB 文件使用 16 MB 分片，失败时通常只需要重传一个 part，而不是从头发送 1 GB。分片越小，重试粒度越细，但请求数量和服务端记录也会增加；分片越大，管理开销变少，却会放大单次失败的损失。

工程上可以先用 8–32 MB 做一轮压测：记录平均吞吐、P95 单片耗时、同时上传任务数和 JVM 堆使用，再决定是否上调。不要仅看单个请求最快，上传接口还要给下载、缩略图和业务 API 留出出口带宽。

Java 里的最小调用链

一条可回归的 multipart 链路至少包含三个动作：CreateMultipartUpload 取得 uploadId，UploadPart 按 partNumber 上传并保留 ETag，CompleteMultipartUpload 提交全部已确认的分片。任何一个 part 失败，都不能把尚未确认的 ETag 当作成功结果。

CompletableFuture started =
    s3AsyncClient.createMultipartUpload(CreateMultipartUploadRequest.builder()
        .bucket(bucket)
        .key(objectKey)
        .build());

// 每个 part 完成后保存 partNumber 和 ETag
UploadPartRequest request = UploadPartRequest.builder()
    .bucket(bucket)
    .key(objectKey)
    .uploadId(uploadId)
    .partNumber(partNumber)
    .contentLength(length)
    .build();

s3AsyncClient.uploadPart(request, AsyncRequestBody.fromFile(partFile))
    .thenApply(result -> CompletedPart.builder()
        .partNumber(partNumber)
        .eTag(result.eTag())
        .build());

这里的关键不是把所有 future 一次性提交，而是用受控并发限制同时存在的分片任务数。任务队列满时让上游慢下来，避免大文件上传把 Tomcat 工作线程、HTTP 连接池和堆内缓冲一起推高。

失败重试要围绕分片而不是整文件

单个 UploadPart 失败时，只重试该 part，并继续使用原来的 uploadId。重试次数要有上限，且同一个 part 的重试间隔应带一点退避；如果 uploadId 已过期、鉴权失败或对象键被业务取消，就不应该无限重试。

try {
    List parts = uploadPartsWithLimit(file, uploadId, maxInFlight);
    s3AsyncClient.completeMultipartUpload(CompleteMultipartUploadRequest.builder()
        .bucket(bucket)
        .key(objectKey)
        .uploadId(uploadId)
        .multipartUpload(CompletedMultipartUpload.builder().parts(parts).build())
        .build()).join();
} catch (RuntimeException failure) {
    s3AsyncClient.abortMultipartUpload(AbortMultipartUploadRequest.builder()
        .bucket(bucket).key(objectKey).uploadId(uploadId).build()).join();
    throw failure;
}

真实系统还要把 uploadId、objectKey、partNumber、重试次数和最终状态写入可检索日志。这样用户重试时可以判断是重新开始，还是恢复一个仍然有效的上传任务；不要把临时文件路径或访问凭据直接写进日志。

上线前用四个检查点收口

• 内存：单个分片缓冲与同时上传数相乘后，仍低于 JVM 堆的安全余量。
• 带宽：压测时同时观察上传接口和其他 API 的延迟，不只看文件传输速度。
• 完整性：CompleteMultipartUpload 只接收已经拿到 ETag 的 part。
• 清理：取消、超时和最终失败都要触发 AbortMultipartUpload，并在对象存储侧配置未完成上传的清理策略。

相关问题

分片越小是不是一定更快？

不是。分片变小会增加请求和调度开销，只有在失败率较高或需要更细重试粒度时才更有价值。

异步客户端是否代表可以无限并发？

不是。异步只改变等待方式，并不消除连接池、带宽、CPU 和对象存储请求配额的约束。

上传中断后能否永远保留 uploadId？

不能把它当成永久任务。恢复策略要配合有效期、业务取消和服务端未完成上传清理规则设计。

总结

Java 大文件上传的方案选择，核心是把单片大小、并发度、失败边界和清理动作放在同一张设计表里。先用小规模压测找到内存与带宽的平衡点，再让 UploadPart 级别重试承担网络波动，最后用 CompleteMultipartUpload 和 AbortMultipartUpload 形成成功与失败的闭环。