Java 文件上传如何限制内存：Multipart 配置、临时文件与清理验收

线上导入接口突然出现内存抖动时，上传文件往往比业务代码更早暴露问题：一个 20 MB 文件在低并发下没事，几十个请求同时到达就可能把堆顶满。Java 的 Multipart 上传控制不能只填一个“最大文件大小”，还要把内存阈值、临时目录、并发容量和清理结果一起验收。

先把“文件大”与“内存高”分开看

上传限制至少有三层：单个文件允许多大，一次请求允许带多少文件，以及解析阶段允许在内存里暂存多少内容。前两层是业务边界，后一层是资源边界。把三者写成同一个数字，通常会让排查变得含糊。

例如接口允许单文件 50 MB，但内存阈值只有 256 KB，那么大部分内容应当落到临时目录；如果仍然有 50 个并发请求，每个请求都占用解析缓冲和元数据，堆内存依然会受到并发放大。下面这张图先把两条路径分开，便于对照配置。

按三段配置搭出可控的上传边界

第一段是应用层的请求与文件大小限制。Spring Boot 项目通常通过 Multipart 相关配置设置单文件和单请求上限；不同版本的属性名可能略有差异，发布前应以当前项目依赖对应的官方配置元数据为准。第二段是内存到临时文件的切换阈值，目标是让大文件尽快脱离堆内存。第三段是临时目录本身：路径、可用空间、权限和清理策略都要单独检查。

# application.properties 示例，数值按业务容量调整
spring.servlet.multipart.max-file-size=50MB
spring.servlet.multipart.max-request-size=60MB
spring.servlet.multipart.file-size-threshold=256KB
spring.servlet.multipart.location=/srv/app/upload-tmp

这里的数字不是通用答案。若业务要接收图片，50 MB 可能已经偏大；若是批量压缩包，单请求总量又可能需要结合反向代理、应用实例内存和磁盘配额一起计算。配置变更后先重启一个灰度实例，不要直接全量替换。

代码边界要挡住“读进内存再处理”

配置只负责约束入口，业务代码仍然可能把整个文件读成字节数组。上传落盘或交给下游处理时，应优先使用流式路径，并在业务层再次检查文件名、类型、大小和目标目录。临时文件名不要直接来自客户端；落盘完成后再做哈希或格式检查，失败路径也要进入清理逻辑。

@PostMapping("/imports")
public ResponseEntity importFile(@RequestPart("file") MultipartFile file) throws IOException {
    if (file.isEmpty() || file.getSize() > MAX_BYTES) {
        return ResponseEntity.badRequest().body("file rejected");
    }

    Path staged = Files.createTempFile(stagingDir, "upload-", ".bin");
    try (InputStream input = file.getInputStream();
         OutputStream output = Files.newOutputStream(staged)) {
        input.transferTo(output);
        verifySizeAndDigest(staged);
        processStagedFile(staged);
        return ResponseEntity.ok("accepted");
    } finally {
        Files.deleteIfExists(staged);
    }
}

示例中的 `verifySizeAndDigest` 要读取实际落盘结果，而不是只相信请求头；`processStagedFile` 也应该明确是否需要重复读取。若业务需要异步处理，可以把文件转移到任务目录，再由任务完成后删除，不能在接口返回后无条件删掉仍被后台使用的文件。

上线前按一条完整链路验收

先用略小于单文件上限的文件验证成功路径，再用超过单文件上限和超过单请求上限的输入验证拒绝路径。每次测试都观察应用堆、GC 暂停、临时目录文件数量和磁盘剩余空间。真正有价值的结果不是“接口返回 200”，而是大文件期间堆峰值没有随文件大小线性增长，失败请求结束后临时目录能回到基线。

# 只观察指标，不把客户端文件内容写入日志
jcmd  GC.heap_info
du -sh /srv/app/upload-tmp
find /srv/app/upload-tmp -type f | wc -l

灰度阶段建议记录四个数：并发上传量、最大堆占用、临时目录峰值文件数、失败后残留文件数。最后一个数必须为零或符合明确的异步保留规则。若磁盘先到上限，应用应返回可识别的失败状态，并触发告警，而不是继续接受请求直到实例失去响应。

相关问题：上传内存与临时文件

下面几个问题在配置评审时最容易被混在一起，单独核对能减少误调参数的情况。

文件大小限制是否能替代内存限制？

不能。文件大小限制阻止过大的输入，内存阈值决定解析内容何时转入临时存储；并发量还会放大每个请求的固定开销。

临时目录为什么会越积越多？

常见原因是异常路径没有清理、异步任务仍持有文件，或者容器重启后没有独立的清理任务。要先区分“仍在使用”和“孤儿文件”，再决定删除策略。

验收时只看堆曲线够吗？

不够。堆曲线正常但磁盘被临时文件填满，同样会造成上传失败。堆、GC、磁盘空间、文件数量和失败响应应放在同一轮测试里核对。

把配置变成可回退的发布清单

先在一台实例上启用阈值与临时目录，验证小文件、大文件、超限输入和中途断开四类结果；再观察一个完整业务高峰。若堆峰值下降但临时目录增长异常，优先回查清理生命周期和异步转移规则，而不是继续调低内存阈值。只有成功、拒绝、清理和回退四条路径都有记录，Multipart 配置才算真正交付。