1. 为什么百M大文件一到SpringMVC手里就死给你看先说一个我经常在项目里见到的场景某系统上线半年都好好的突然某天用户上传一个120MB的设计稿压缩包前端转了半天圈后端直接报OutOfMemoryErrorTomcat挂掉全员遭殃。排查日志时代码写得很干净——RequestParam(file) MultipartFile file然后file.getBytes()交给后续处理。问题恰恰出在这条人畜无害的代码链上。SpringMVC本身只是门面底层走的还是Servlet规范。默认情况下一个MultipartFile对象会先把整个请求体吃进内存内存里放不下再往临时目录刷。具体表现由两个参数决定file-size-threshold是内存阈值默认0意味着只要超过0字节就直接落盘max-file-size限制单文件大小Spring Boot默认1MBSpring MVC纯XML配置则取决于Servlet容器。很多项目中这两个参数被调大之后比如max-file-size设成500MB看似能传了但是getBytes()这个方法会强行把整个文件再拉回内存。500MB打进JVM堆里GC直接进入生无可恋模式吞吐量掉到冰点极端情况下就是OOM。下载方向也没好到哪去。很多人习惯写ResponseEntitybyte[]内部再调FileUtils.readFileToByteArray或者Files.readAllBytes逻辑上爽快可文件一到百M级别这一行代码就是一颗炸弹它要先创建一个和文件等大的byte数组把整个文件读进堆内存再交给Spring框架输出。100MB的文件至少吃掉200MB以上的内存byte数组本身拷贝过程中的临时对象QPS稍微一上来堆直接爆炸。还有一类问题是隐形的——超时。客户端上传100MB文件走普通宽带快的时候几秒钟慢的时候移动网络、跨地域传输轻松超过60秒。Tomcat的connectionTimeout默认20秒Nginx的client_body_timeout默认60秒任何一个超时都会让连接被中间层切断。前端看是上传失败请重试后端日志什么都没打因为请求根本没完全进来。这是大附件场景里最容易被忽视的三不管地带不怪SpringMVC不怪代码怪你没有看清整个链路里每一层的超时和大小限制。所以大附件处理的本质不是让SpringMVC能接收大文件而是绕开SpringMVC默认的舒适区用Servlet规范提供的流式能力去手动接管数据通道。理解这一点后面所有的改造就顺理成章了。2. 上传改造从饭来张口到边接边存2.1 核心思路把MultipartFile当接口看别当保险箱MultipartFile提供了三个常用获取数据的方式getBytes()、getInputStream()、transferTo(File dest)。绝大多数人只认识getBytes()然后踩坑transferTo()其实已经是框架级优化底层会把临时文件直接rename或者用流复制比getBytes()内存友好很多但它在某些容器和相对路径组合下有个著名坑transferTo的javadoc写的是把接收到的文件转移到目标文件但如果你传的是相对路径它会相对于临时目录去解析而不是当前工作目录。也就是说你代码里写file.transferTo(new File(upload/abc.zip))实际文件可能被挪到/tmp/upload/abc.zip因为Tomcat的临时目录是/tmp。这个坑我在某跨平台系统项目里踩过一次排查了半天最后发现文件都在/tmp下躺着。最稳妥的方案不要依赖MultipartFile的便捷方法直接从HttpServletRequest拿Part再从Part拿InputStream自己用缓冲区手动写文件。这样内存占用由你控制文件路径也完全由你说了算还顺手解决了transferTo相对路径的坑。2.2 配置层该放开的放开该守住的守住无论你用Spring Boot的application.yml还是传统web.xml都要做两层配置。Spring Boot场景application.yml里加上spring: servlet: multipart: enabled: true max-file-size: 1024MB max-request-size: 1024MB file-size-threshold: 2MB纯XML场景在web.xml的servlet配置里加multipart-config max-file-size1073741824/max-file-size max-request-size1073741824/max-request-size file-size-threshold2097152/file-size-threshold /multipart-config注意一个容易被忽略的逻辑max-file-size是单个文件上限max-request-size是整个请求体的上限。如果你的接口允许一次传多个文件max-request-size必须比max-file-size大否则传两个60MB文件的时候请求会被拦截但日志里你只能看到令人绝望的the request was rejected because its size exceeds the configured maximum。file-size-threshold我习惯设成2MB或4MB。这个值决定文件在内存里累积到多少之后再落盘临时文件。设大了一点比如32MB在文件都不大的场景能提升性能但百M场景千万别设太大不然并发一上来每个上传请求都先在堆里攒32MBGC先受不了。2.3 代码层手动接管InputStream落盘可控可查配置完成后Controller可以写成这样PostMapping(/upload) public String upload(HttpServletRequest request) throws Exception { String fileName null; // 注意如果表单里mixed了多个文件字段需要遍历request.getParts() for (Part part : request.getParts()) { String submittedFileName part.getSubmittedFileName(); if (submittedFileName null || submittedFileName.isEmpty()) { // 非文件字段普通表单字段 continue; } // 处理文件名防路径穿越只保留文件名部分 String safeName new File(submittedFileName).getName(); fileName UUID.randomUUID().toString() _ safeName; File dir new File(/data/upload); if (!dir.exists()) { dir.mkdirs(); } File target new File(dir, fileName); try (InputStream in part.getInputStream(); FileOutputStream out new FileOutputStream(target)) { byte[] buffer new byte[64 * 1024]; int len; long total 0; while ((len in.read(buffer)) ! -1) { out.write(buffer, 0, len); total len; } // 如果后续需要记录大小total就是文件的真实字节数 } } return fileName; }这里有两个值得说道的点。第一为什么缓冲区选64KB而不是8KB8KB是很多教程里默认的StreamingOutput缓冲区但实测下来在百M文件场景中64KB到128KB的缓冲区能明显减少read和write系统调用的次数磁盘顺序写的吞吐量会更高。太大也没必要1MB的缓冲区在这种场景里收益微乎其微反而白白占用内存。第二part.getSubmittedFileName()是Servlet 3.1才有的方法它能直接从Part上拿到客户端上传的原始文件名。有些老项目用的Servlet 3.0就只能手动解析part.getHeader(content-disposition)里的filename字段那个解析代码写起来很烦要注意引号和编码。2.4 为什么这种写法更抗造内存账算给你看我拿一个100MB文件为例对比两种写法的内存账。传统写法MultipartFile.getBytes()→ 第一步容器把整个请求体接进来超过file-size-threshold的部分已经落到临时文件第二步getBytes()把磁盘上的临时文件整个读入堆内存创建一个100MB的byte数组第三步后续处理比如计算MD5再创建一份等大数组。高峰期3个并发上传光是上传逻辑就吃掉600MB堆。流式写法不管请求体多大内存里始终只有64KB缓冲区加少量元数据。磁盘上临时文件在写入过程中确实会占100MB空间但那不占JVM堆。3个并发上传堆内存占用几乎可以忽略吃的是磁盘I/O。这就是边接边存和先收完再处理的本质区别。数据流到了就写盘写完就释放内存永远有边界。3. 下载改造别把整个文件扛进堆里再发出去3.1 两种流式输出的正确姿势下载比上传简单一些但踩坑的人同样不少。最典型的错误是用ResponseEntitybyte[]返回文件内容这个前面分析过内存账就不再重复了。正确的思路是让SpringMVC只负责把OutputStream交给Servlet容器数据由你自己往流里灌灌的过程中内存占用始终可控。第一种姿势直接用HttpServletResponse.getOutputStream()写。GetMapping(/download/{fileId}) public void download(PathVariable String fileId, HttpServletResponse response) throws IOException { // 模拟根据fileId找到磁盘上的文件 File file findFileById(fileId); response.setContentType(application/octet-stream); response.setHeader(Content-Disposition, attachment;filename*UTF-8 URLEncoder.encode(file.getName(), UTF-8)); response.setContentLengthLong(file.length()); try (InputStream in new FileInputStream(file); OutputStream out response.getOutputStream()) { byte[] buffer new byte[64 * 1024]; int len; while ((len in.read(buffer)) ! -1) { out.write(buffer, 0, len); } out.flush(); } }注意几个细节setContentLengthLong不能用setContentLength那个方法接收的是int100MB以上的文件int装不下会变成负数导致浏览器行为异常。filename*UTF-8是RFC 5987的标准写法用来处理中文文件名。URLEncoder.encode之后把空格变成这在Content-Disposition里其实不合规更严谨的做法是手动把替换成%20。实测主流浏览器都能正确处理但如果你在旧版IE上测试还是老老实实用filename加filename*双写兜底。第二种姿势用ResponseEntityFileSystemResource让Spring帮你处理流。GetMapping(/download/{fileId}) public ResponseEntityFileSystemResource download(PathVariable String fileId) { File file findFileById(fileId); FileSystemResource resource new FileSystemResource(file); return ResponseEntity.ok() .header(HttpHeaders.CONTENT_DISPOSITION, attachment;filename*UTF-8 URLEncoder.encode(file.getName(), UTF-8)) .contentType(MediaType.APPLICATION_OCTET_STREAM) .contentLength(file.length()) .body(resource); }这种方式代码更简洁FileSystemResource底层走的是InputStreamResource的流式逻辑不会把文件装进内存但前提是不要用byte[]或ByteArrayResource包装。很多人倒在这一步觉得Resource就安全了结果用ByteArrayResource包了一下白瞎了流式设计。3.2 零拷贝与sendfileTomcat帮你省的最后一道力如果文件在本地磁盘且Tomcat配置得当流式输出的最终形态是零拷贝。Servlet容器在输出响应时如果识别到你的OutputStream是原生的ServletOutputStream且未被包装底层能触发sendfile系统调用让数据直接从磁盘文件发送到网卡完全绕过JVM堆和用户态缓冲区。这意味着下载100MB文件时JVM堆内存几乎零消耗连那64KB缓冲区都快省了。触发sendfile的前提条件比较苛刻响应内容不能经过压缩过滤器的处理。一旦你配置了CompressionFilter或者在代码里直接对OutputStream做了包装sendfile就会失效退回普通拷贝。所以压测下载接口时要特别留意是不是有全局压缩过滤器在暗地里帮你把性能拉低。如果你用的是Nginx做前置代理Nginx的sendfile on也要开着否则到Nginx这一层又会复制一遍。3.3 大文件下载的Range支持该不该做我的建议如果有断点续传或分片下载需求Range支持值得做如果只是给浏览器一个完整的另存为可以先不做但要预留好。Range请求的本质是客户端带着Range: bytes0-1048575来访问服务端返回206 Partial Content和指定区间的字节。实现它不需要引入新的依赖解析请求头然后调整InputStream的起点即可。一个基础版本的做法是String rangeHeader request.getHeader(Range); if (rangeHeader ! null rangeHeader.startsWith(bytes)) { long start Long.parseLong(rangeHeader.substring(6).split(-)[0]); long end Math.min(start 1024 * 1024 - 1, file.length() - 1); response.setStatus(HttpServletResponse.SC_PARTIAL_CONTENT); response.setHeader(Content-Range, bytes start - end / file.length()); // 设置Accept-Ranges: bytes并跳过inputStream的前start个字节 }这里有个小坑skip方法在FileInputStream上返回的是实际跳过的字节数有些实现比如BufferedInputStream在skip超过一定值时可能不准稳妥做法是循环调用skip直到累计跳过指定长度。另外Range解析要容错遇到bytesabc这种情况直接返回416 Range Not Satisfiable否则客户端会莫名卡死。4. 链路排障Nginx、Tomcat、临时目录、网络超时一处都不能漏4.1 前置Nginx的两行配置定生死很多系统上传下载走的是浏览器 → Nginx → Tomcat 的链路。Nginx默认client_max_body_size只有1MB你没改的话前端传一个2MB的文件就会收到413 Request Entity Too Large而且Tomcat日志里干干净净因为请求根本就没到后端。需要调整的配置集中在http块或server块client_max_body_size 1024m; client_body_buffer_size 128k; client_body_temp_path /tmp/nginx_body_temp; client_body_timeout 120s;client_body_buffer_size是Nginx接收请求体时在内存里的缓冲区超过就落盘到client_body_temp_path指定的临时目录。这个值不用设太大128k就够落盘也不慢。真正要留意的是临时目录的剩余磁盘空间如果系统盘只有8G用户连续传几个大文件Nginx会先把请求体在临时目录写好再转发给后端磁盘一旦写满报错会非常诡异——有时是500 Interal Server Error有时是连接中断。client_body_timeout默认60秒如果用户上传很慢比如2G文件传到一半卡住达到这个值Nginx会断开连接。4.2 Tomcat侧配置与maxSwallowSize这个隐藏刺客Tomcat侧需要开的配置主要有两个。第一是连接器本身的参数在server.xml的Connector里Connector port8080 protocolHTTP/1.1 connectionTimeout120000 maxSwallowSize2097152 maxPostSize10485760/connectionTimeout从默认的20秒调到120秒给大文件上传留出余量。maxSwallowSize这个参数非常隐蔽它的作用是当客户端上传请求已被处理完比如代码提前抛异常返回了Tomcat会尝试把剩余的数据吞掉以复用连接。默认值2MB意味着如果请求体还剩超过2MB没读完Tomcat会直接抛异常——你会在日志里看到类似More than the maximum number of request body bytes have been read的报错。解决方法是把这个值调大比如-1表示不限制或者直接设成和max-file-size一致。很多团队排查线上环境上传大文件必现500传小文件没问题根因往往就是这个参数。第二是Spring层的multipart配置前面已经写过max-file-size和max-request-size设成一致且足够大file-size-threshold设成合理值。这里补充一个判断标准max-request-size必须覆盖你的真实业务场景。假设接口最多同时接收5个200MB的文件那max-request-size至少是1024MB。这个参数如果设小了连到中间层Nginx都救不了你。4.3 服务端临时目录权限、空间、清理一个都不能少上传过程中Servlet容器会把超过file-size-threshold的文件写入javax.servlet.context.tempdir指定的目录通常是Tomcat的/temp或系统的/tmp。几个常见的生产事故根源/tmp目录权限不对容器进程写不进去上传直接报IOException: No space left on device——但这句话有时候是误导实际可能是权限拒绝。/tmp所在分区被其他应用写满容器在写临时文件时IO异常。临时文件未及清理长时间跑下来堆积了几十GB垃圾文件。我的建议如果你手动接管了InputStream文件已经写到了自己的/data/upload目录那javax.servlet.context.tempdir就只在容器尚未交给你InputStream之前短暂使用量级很小基本不用管。但如果你依赖了MultipartFile.transferTo()这个临时目录的清理就很重要因为transferTo在Tomcat上其实是移动临时文件移动失败时会回退到复制再删除删除失败就会留下孤儿临时文件。系统卷空间告急时要留意这个目录。4.4 并发上传时的Tunning别让线程池成了瓶颈耗尽内存的问题解决了下一个瓶颈往往是Tomcat的线程池。默认配置下Tomcat最大线程数maxThreads是200maxConnections稍大一些。大文件上传的特点是单个请求占用时间长几十秒甚至几分钟一个线程在处理某个大文件时这个线程无法服务其他请求。当同一个时刻有20个用户上传100MB文件即使你的机器性能很好Tomcat线程池也可能被打满其他所有接口包括查询列表这种轻接口全部超时。对应措施有两个方向一是把大文件上传接口和其他业务接口的线程池隔离。这种方法需要自定义ThreadPoolExecutor并让Spring MVC用CompletableFuture或者TaskExecutor去异步处理文件落盘逻辑。Controller接收完请求后马上返回文件上传中状态后端线程池慢慢处理。二是把上传请求从业务Tomcat中剥离直接由独立的文件服务处理。这不是SpringMVC范畴了但很多成熟项目确实是这样做的Nginx直接代理文件上传请求到专门的upload服务业务API只负责生成凭证和查询状态。这个架构切分会带来明显收益但初期改造量不小不建议在文章里展开太多知道这个方向即可。5. 从百M到上G分片、断点续传与秒传的落地思路5.1 为什么百M靠流式上了G就得换玩法一百MB级别的文件上面这些方案足够了流式上传、流式下载、超时调优性能瓶颈基本可控。但如果文件涨到1GB、2GB甚至更大你马上会碰到新的三堵墙网络中断一个1GB文件传到800MBWi-Fi闪断整个上传作废用户心态直接爆炸。这个场景里能传已经不稀罕能续传才是刚需。体验问题单次大文件上传没有进度条概念没法看体验很差用户根本不知道传到哪了。服务端压力所有大文件同时涌入临时空间瞬间吃紧合并操作对磁盘I/O的冲击非常大。这个阶段的核心思路是分片上传前端把大文件按固定大小切成若干片一片一片独立上传每片上传成功后后端记录状态全部传完后后端按顺序合并。分片理论上有两重收益一是单片失败只需重传这一片而不是整个文件天然抗网络抖动二是单片大小可控比如5MB服务端每次只需要处理5MB的请求内存压力和超时风险大大降低。5.2 分片上传的后端设计从搭积木到拼积木后端分片接口的设计模式并不复杂核心是三个接口// 1. 初始化上传会话前端拿到uploadId POST /upload/init // 返回: { uploadId: uuid, chunkSize: 5242880, totalChunks: 200 } // 2. 上传单片数据 POST /upload/chunk // 参数: uploadId, index, totalChunks, data // 后端把data写入 ${uploadId}/${index}.part // 3. 合并分片 POST /upload/merge // 参数: uploadId, fileName // 后端把 ${uploadId} 目录下所有part按index排序合并成最终文件合并分片的代码可以参考这样写利用FileChannel.transferTo做零拷贝合并File dir new File(uploadDir, uploadId); File[] parts dir.listFiles((d, name) - name.endsWith(.part)); Arrays.sort(parts, Comparator.comparingInt(f - Integer.parseInt(f.getName().replace(.part, )))); File merged new File(uploadDir, finalFileName); try (FileChannel out new FileChannel.open(merged.toPath(), StandardOpenOption.CREATE, StandardOpenOption.WRITE)) { for (File part : parts) { try (FileChannel in FileChannel.open(part.toPath(), StandardOpenOption.READ)) { in.transferTo(0, in.size(), out); } } } // 合并完成后删除分片目录 FileUtils.deleteDirectory(dir);有个细节要注意FileChannel.transferTo在合并大文件时确实高效但它是站在操作系统帮你搬运的视角如果跨文件系统比如NFS挂载可能会静默失败返回部分长度稳妥做法是写个循环判断transferred remaining。分片大小怎么定如果内网部署50MB一片没有问题如果是公网环境弱网用户5MB左右比较稳妥。前端用File.slice(start, end)切出来的分片天然带起始偏移后端按index存就行不需要重复校验文件内容偏移——index已经够了。5.3 秒传与断点续传能用MD5解决的不必上重型方案秒传听起来玄乎原理很简单文件上传前前端先把文件做一个MD5摘要后端拿到这个摘要去文件存储表里查如果发现相同摘要且大小一致的文件直接返回上传成功并关联到已有文件记录不需要真的传输。一个基础做法是PostMapping(/upload/check) public UploadCheckResult check(RequestBody CheckRequest req) { File existing findByMd5AndSize(req.md5, req.size); if (existing ! null) { // 秒传直接把用户文件记录关联到existing return UploadCheckResult.existed(existing.id); } return UploadCheckResult.notExisted(); }注意MD5对大文件来说计算耗时不小前端在弱设备上算一个1GB文件的MD5可能要几十秒。替代方案是先按文件大小和文件头/尾的片断做初筛命中后再算全量MD5。断点续传在分片体系里天然存在每片上传成功后前端记录已传分片索引重连后只需重新上传未成功的片。服务端也可以提供一个查询已上传分片的接口让前端在断网恢复后主动同步状态避免盲目重传。5.4 何时该上对象存储而不是继续堆SpringMVC代码聊到这里需要泼一盆冷水如果项目的大文件场景持续扩大比如亿级用户平台继续在SpringMVC里堆代码不是不可以但会越来越累。Nginx上传临时目录的磁盘规划、多节点部署时文件服务器的一致性、合并操作对CPU的冲击、存储备份机制——这些都是绕不开的运维负担。成熟的方案是使用对象存储服务把大文件直接传给对象存储的临时凭证接口业务服务只做元数据管理。这个切换不需要推翻SpringMVC的上传架构而是将接收文件并落盘这一层从业务服务里剥离出去。但要说明的是如果只是企业内部系统、文件量有限、并发不高在自己服务器上用Nginx加独立磁盘做文件目录配合SpringMVC的流式接口完全够用且成本更低。技术选型永远看场景不追潮流。6. 我在实战中反复用到的几条原则文章写到这里主体方案都讲完了。最后沉淀几条我自己的实操原则不一定是教科书标准但都是从线上故障里活下来的经验。第一永远不要在代码里让一个文件占满你的JVM堆。无论是上传的getBytes还是下载的byte[]这两路由大文件触发的内存峰值是整个业务系统里最危险的不确定因素。宁可多写几行流式代码也别贪图几行代码的爽快。第二调参前先看完整链路。别一上来就改Spring的multipart配置。先理清楚Nginx的client_max_body_size是多少Tomcat的maxSwallowSize是多少中间还有没有别的代理层一次上传请求走完整个链路每一层都有自己的限制任何一个环节没放开都会得到失败的结果且日志不一定能帮你定位到那一层。第三临时目录要有专人看管。无论是Nginx的client_body_temp_path、Tomcat的临时目录还是你自己的上传目录都要设置配额监控要定期清理。大文件系统的磁盘满事故几乎从来不是一夜之间出现的而是三周前的某个配置失误慢慢积累出来的。第四分片接口必须做幂等。前端网络抖动导致重复上传同一分片时后端不能报错也不能产生重复文件。设计上最好让每个分片的写入是覆盖式的同一个index的分片只保留一份。合并时发现缺片返回明确的错误码和缺失索引列表这样前端前端可以实现精准补传。大附件处理没有银弹。百M级别靠流式方案已经能解决得比较舒服上G级别就要考虑分片、断点续传、对象存储的组合方案。但无论方案怎么演进数据流有界内存不失控这八个字始终是设计时最该守住的底线。
