这段时间在给一个传统Java Web项目做升级遇到了一个很实际的需求业务系统里要上传几十MB到几百MB的视频素材还有一批几十MB的Excel报表。原来直接走表单提交文件结果一到50MB以上就频繁超时、连接重置甚至Tomcat直接报Request header is too large或者IOException: Connection reset by peer。折腾了一个多星期最终用JSP页面Servlet的方式实现了大文件分块上传把一套完整的流程跑通了。这篇文章我就把这个方案的方方面面拆开来讲包括前端切片、后端接收、合并校验、断点续传以及线上环境容易踩的坑全部是实际项目中验证过的做法适合正在做传统Java Web开发、或者想理解分块上传原理的朋友参考。先说结论分块上传的核心思路是把一个大文件切成多个小块分别上传最后服务端按顺序合并。这样做能够绕开HTTP连接超时、服务器单次请求体大小限制、网络波动导致整包重传的问题。整体流程听起来不复杂但真正落地的时候细节非常多尤其是服务端的分块存储、合并时机、并发控制这几个环节稍不注意就会丢块、文件损坏、甚至把服务器磁盘打满。1. 分块上传到底解决了什么问题1.1 一次性上传大文件的三个瓶颈很多人觉得大文件上传无非就是“把maxPostSize调大一点”真不是这么回事。我在项目里实际碰到过三类问题第一服务器限制。Tomcat 8以后内置的maxPostSize默认是2MB注意是表单POST请求体的最大值不是文件大小。虽然可以通过修改server.xml里的maxPostSize-1去掉限制但去掉之后还有第二层问题。第二网络中断成本太高。一个300MB的文件传了280MB突然断网或者服务器超时整个请求作废从头再来。前端用户的心态可能直接崩溃运维同学的后台日志也惨不忍睹。第三HTTP连接超时。默认的连接和读取超时在代理层比如Nginx一般是60秒。如果网速只有1MB/s传一个100MB的文件需要100秒中间某个瞬间稍微慢一点连接就被掐断了。1.2 分块上传是怎么化解这些问题的分块上传的思路非常直白把大文件切成比如每块5MB的小片一块一块独立上传。每一块都是一次独立的HTTP请求单块体积小传输时间短不容易触发超时某一两块失败可以单独重试不需要整包重来服务器端每块单独落盘等所有块到齐后再合并。用一个生活化的类比快递一个大型家具如果整件邮寄运输途中损坏了就得全损理赔。如果拆成木板和零件分批发哪个零件坏了补发哪个最后收货人自己组装整体上效率和可靠性高得多。不过这里要说清楚分块上传适合的是50MB以上的文件尤其是几百MB到几GB的视频、压缩包。如果只是几MB的小文件分块上传反而会把简单问题复杂化——额外多了切片、合并、存储管理的开销不值得。建议把分块上传的触发阈值设为30MB或者50MB小于阈值的文件走普通上传就行。1.3 集成JSP页面时整体流程图整套方案的执行流程我拆成四个步骤来设计前端选取文件后计算文件唯一标识一般用MD5按固定大小切成多个分块。前端依次上传每个分块同时附带文件标识、分块序号、总分块数。服务端每个分块到达后以“文件标识_分块序号”为文件名存到临时目录。当前端确认所有分块上传完成后通知服务端合并服务端按分块序号顺序读取写入最终文件。这个过程听起来简单可实操中有几个关键设计必须提前想清楚接下来我分别展开讲。前端切片是第一步它在整个链路里决定了后续数据结构的形态。2. 前端切片JSP页面里的JavaScript需要完成的核心逻辑2.1 获取File对象与切片参数设计在JSP页面里因为最终要渲染到浏览器端执行所以切片逻辑全部由JavaScript完成。使用的浏览器API是File对象的slice方法。注意File.slice()在不同浏览器中的兼容性没问题现代浏览器都支持。具体切法如下// 每个分块大小建议5MB~10MB这里以5MB为例 const CHUNK_SIZE 5 * 1024 * 1024; // file 来自 input[typefile] 的 files[0] function createChunks(file) { var chunks []; var start 0; var index 0; while (start file.size) { var end Math.min(start CHUNK_SIZE, file.size); var blob file.slice(start, end); chunks.push({ index: index, blob: blob, size: blob.size }); start end; index; } return chunks; }为什么分块大小选5MB我做过对比如果分块太小比如1MB一个500MB的文件会切成500个分块HTTP请求数量太多请求头、网络往返带来的额外开销会拖慢整体速度如果分块太大比如50MB遇到弱网环境单块成功率又会下降。在实际项目里5MB到10MB是一个比较合适的区间既不会让请求数过于夸张又能有效降低单块传输失败的概率。2.2 计算文件唯一标识MD5与文件指纹分块上传最关键的一个点是——服务端怎么知道哪个分块属于哪个文件这里需要给文件算一个唯一标识。最常用的方案是计算整个文件的MD5值用它作为文件ID。// 简单示意如何对文件内容进行MD5计算 // 项目中可以引入现有的MD5计算库通过FileReader分段读取文件内容累加计算 function computeFileMd5(file, callback) { var fileReader new FileReader(); var chunkSize 2 * 1024 * 1024; var offset 0; var spark new Md5(); // 假设有一个支持增量计算的MD5工具对象 function loadNext() { var slice file.slice(offset, offset chunkSize); fileReader.readAsArrayBuffer(slice); } fileReader.onload function(e) { spark.append(e.target.result); offset chunkSize; if (offset file.size) { loadNext(); } else { callback(spark.end()); } }; loadNext(); }这里有个细节要提醒MD5计算是在浏览器端完成的如果文件有几GB计算MD5的过程可能会占用不少内存和时间用户会看到页面短暂“卡住”。建议在计算前先弹出一个进度提示而不是干等着。此外MD5只是用来做文件标识和完整性校验不是安全意义上的加密不要混淆这个概念。2.3 逐个上传分块XMLHttpRequest的应用切片完成后需要把每个分块上传到服务端。这里使用的是XMLHttpRequest的upload对象因为可以监听上传进度。上传时每个分块都要带上四类信息文件标识fileMd5、分块序号chunkIndex、总分块数totalChunks、原始文件名fileName。function uploadChunk(fileMd5, chunk, totalChunks, fileName) { return new Promise(function(resolve, reject) { var formData new FormData(); formData.append(fileMd5, fileMd5); formData.append(chunkIndex, chunk.index); formData.append(totalChunks, totalChunks); formData.append(fileName, fileName); formData.append(file, chunk.blob, fileName _ chunk.index); var xhr new XMLHttpRequest(); xhr.open(POST, ${pageContext.request.contextPath}/upload, true); xhr.timeout 60000; xhr.onload function() { if (xhr.status 200) { resolve(xhr.responseText); } else { reject(new Error(HTTP xhr.status)); } }; xhr.onerror function() { reject(new Error(网络错误)); }; xhr.ontimeout function() { reject(new Error(请求超时)); }; // 关键进度事件可以从 xhr.upload 中获取 xhr.upload.onprogress function(e) { if (e.lengthComputable) { // 可以回调出去更新进度条 console.log(分块 chunk.index 进度: Math.round(e.loaded / e.total * 100) %); } }; xhr.send(formData); }); }值得注意的是方法里把分块文件命名成“文件名_分块序号”这是为了调试方便服务端在临时目录里看到文件时能直观知道这个分块属于谁。不过真正存储时服务端应该重新按fileMd5_chunkIndex来命名避免不同用户上传同名文件导致混淆。2.4 上传全部块与合并通知所有分块依次上传完成后还需要一个合并动作。合并可以设计成前端通知服务端“文件所有分块已经就绪请合并”也可以由服务端在每次上传分块时判断“总分块数是否都已经有了”。我推荐后者原因下面会详细说。前端的核心逻辑大致如下async function uploadAllChunks(file) { var fileMd5 await computeFileMd5(file); var chunks createChunks(file); for (var i 0; i chunks.length; i) { await uploadChunk(fileMd5, chunks[i], chunks.length, file.name); } // 所有分块上传完成通知服务端合并 await notifyMerge(fileMd5, chunks.length, file.name); }这里需要注意如果简单用for循环逐个await上传整体会比较慢因为每个分块都要等待上一个完成。后面我会专门讲并发控制的实现这里先用串行逻辑保证正确性避免一开始就陷入并发竞态的泥潭。前端切片这部分整体看下来核心其实是数据结构的设计——文件标识、分块序号、总分块数这三个参数贯穿前后端。接下来是服务端也是整个方案的重头戏。3. 后端接收分块Servlet接口设计与存储约定3.1 接口参数定义服务端我使用的是Servlet 3.0的Part接口来处理上传文件。前端提交的是multipart/form-data格式所有参数都包含在请求体中。接口约定如下参数名类型说明actionString操作类型upload上传分块、check查询已上传分块、merge合并分块fileMd5String文件唯一标识前端计算出的MD5值chunkIndexint当前分块的序号从0开始totalChunksint总分块数fileNameString原始文件名合并时使用filePart分块文件内容接口设计上有个原则服务端不要依赖前端给的totalChunks来验证“是否所以分块都已上传”而应该以临时目录里实际存在的分块数量为准。原因很简单前端可能传错数据或者传多次服务端以自己磁盘上落了几个块为判断依据最可靠。3.2 临时目录结构设计文件存储部分我建议使用一个固定根目录下面按fileMd5建目录内部存放各分块。结构如下/upload_temp/ /abc123def456ghi789/ 0.part 1.part 2.part ... /xyz999.../ 0.part ...加上一个总的文件输出目录/upload_files/ /abc123def456ghi789_原始文件名为什么要加一层以fileMd5为名的目录因为如果直接把所有分块都平铺在一个目录下第一个问题是文件名冲突两个用户同时上传同一个文件名会互相覆盖第二个问题是合并时无法确认这些分块属于哪个文件的哪个阶段。目录隔离之后天然做到按文件聚合。3.3 接收分块的Servlet核心代码MultipartConfig(maxFileSize 10 * 1024 * 1024, // 单个分块最大大小 10MB maxRequestSize 15 * 1024 * 1024, // 整个请求体最大 15MB fileSizeThreshold 1024 * 1024) // 超过1MB写入临时文件 WebServlet(/upload) public class UploadServlet extends HttpServlet { private static final String TEMP_DIR /data/upload_temp; private static final String FILE_DIR /data/upload_files; Override protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { req.setCharacterEncoding(UTF-8); resp.setContentType(application/json;charsetUTF-8); String action req.getParameter(action); String fileMd5 req.getParameter(fileMd5); String fileName req.getParameter(fileName); if (upload.equals(action)) { handleUpload(req, fileMd5); resp.getWriter().write({\code\:0,\msg\:\ok\}); } else if (merge.equals(action)) { int totalChunks Integer.parseInt(req.getParameter(totalChunks)); handleMerge(fileMd5, fileName, totalChunks); resp.getWriter().write({\code\:0,\msg\:\merge success\}); } else if (check.equals(action)) { // 返回已上传分块的索引列表用于断点续传 JSONObject result handleCheck(fileMd5); resp.getWriter().write(result.toJSONString()); } } private void handleUpload(HttpServletRequest req, String fileMd5) throws IOException, ServletException { Part filePart req.getPart(file); int chunkIndex Integer.parseInt(req.getParameter(chunkIndex)); // 构造目标目录 fileMd5 File chunkDir new File(TEMP_DIR, fileMd5); if (!chunkDir.exists()) { chunkDir.mkdirs(); } File chunkFile new File(chunkDir, chunkIndex .part); // 如果分块已经存在大概率是重复上传跳过写入 if (chunkFile.exists()) { return; } // 记录一个上传中的临时文件避免多线程同时写同一个分块 File tmpFile new File(chunkDir, chunkIndex .tmp); try (InputStream in filePart.getInputStream(); OutputStream out new FileOutputStream(tmpFile)) { byte[] buffer new byte[8192]; int len; while ((len in.read(buffer)) ! -1) { out.write(buffer, 0, len); } } // 写完后进行原子重命名防止读取到半截文件 if (!tmpFile.renameTo(chunkFile)) { // 如果重命名失败说明此时合并线程可能已经开始读取chunkFile // 这里直接删除tmpFile即可不让脏文件残留在目录里 tmpFile.delete(); } } }这里有一个容易被忽视但非常重要的小操作先写入一个.tmp临时文件写完再通过renameTo改成.part。为什么要这样做考虑一个场景合并线程正在遍历目录发现0.part存在于是开始读它。但同一时刻某个分块可能才写了一半直接读会读到半个文件。引入.tmp中转文件后合并线程只认.part结尾的文件就不会读到未写完的内容了。3.4 为什么不用共享存储而用本地磁盘很多分布式系统的同学会下意识地想把分块存到共享存储或者对象存储里。对于绝大多数传统Java Web项目来说总量没有大到需要分布式存储的程度直接把临时目录放在服务器本地磁盘反而是风险最小的方案。共享存储一旦出现网络抖动分块写入失败、读取超时排查起来非常痛苦。如果后续并发量确实上来了可以让Nginx做静态文件映射把上传目录指向专用存储节点。这个优化是一步一步来的一开始没必要引入额外复杂度。后端接收分块总算有了雏形但工作只完成了一半。接下来是合并环节这也是最容易出bug的地方。4. 分块合并与完整性校验的实现细节4.1 合并时机服务端判断优于前端通知我见过很多项目采用“前端全部上传完成后发一个通知让后端合并”的方案。这个方案看起来很自然但有一个问题如果前端通知丢失了或者用户传完最后一小块直接关闭浏览器服务端就永远不会合并临时文件一直堆积在磁盘上。我实际采用的是服务端主动判断的方式每次分块上传成功后服务端顺手检查一下该fileMd5目录下的.part文件数量是否等于totalChunks从前端参数里拿到。如果相等说明所有分块都到位了可以立即触发合并。这样即便前端不发合并指令只要最后一个分块到达后端就知道该干活了。当然为了兼容前端主动通知我还是保留了merge接口两者并不冲突。4.2 合并代码实现合并的核心逻辑是按分块序号从0到N读取.part文件依次写入最终文件。这里需要注意两个要点第一要校验分块数量是否和客户端宣称的一致。如果不一致说明有分块丢失直接返回错误让前端重新补齐。第二读取分块时要判断分块文件是否完整存在。之前已经说到通过.part后缀来保证读取的文件是完整落盘的。private void handleMerge(String fileMd5, String fileName, int totalChunks) throws IOException { File chunkDir new File(TEMP_DIR, fileMd5); if (!chunkDir.exists()) { throw new IOException(分块目录不存在无法合并); } // 统计实际分块数量 int actualChunks 0; for (int i 0; i totalChunks; i) { File part new File(chunkDir, i .part); if (part.exists()) { actualChunks; } } if (actualChunks ! totalChunks) { throw new IOException(分块数量不足期望 totalChunks 实际 actualChunks); } File targetDir new File(FILE_DIR); if (!targetDir.exists()) { targetDir.mkdirs(); } File targetFile new File(targetDir, fileMd5 _ fileName); try (OutputStream out new FileOutputStream(targetFile)) { byte[] buffer new byte[64 * 1024]; for (int i 0; i totalChunks; i) { File part new File(chunkDir, i .part); try (InputStream in new FileInputStream(part)) { int len; while ((len in.read(buffer)) ! -1) { out.write(buffer, 0, len); } } } } // 合并成功后删除临时目录及其下所有分块 deleteDirectory(chunkDir); }缓冲区的选择上64KB是比较均衡的。太小如4KB会导致大量系统调用合并速度明显下降太大如1MB会增加内存占用对带宽提升有限。实测下来64KB在传统机械硬盘和SSD上都有不错的吞吐。4.3 大小校验与文件去重合并完成后第二步是校验。最简单有效的校验是比对最终文件的大小与前端声明的原始文件大小是否一致。如果每个分块的大小加起来不等于原文件大小说明传输过程中有分块内容损坏需要前端重新上传该分块。这个校验逻辑放在前端计算文件大小时随fileName一起传给后端。更严格的做法是比对整个文件MD5但服务端拿到的是分块内容逐块计算MD5再总起来校验实现复杂度稍高。我的经验是在一般业务系统里“总分块大小之和等于原文件大小”加上“分块数量正确”这两条已经能拦住99%的问题。文件级MD5校验可以作为可选配置如果需要更严格的完整性保障再开启。这里还有一个小技巧合并时可以在目标文件名里加上fileMd5前缀。如果同一个文件被重复上传前端算出的MD5一致后端发现目标文件已经存在可以直接返回“秒传”成功。这就是分块上传附带的一个额外红利——天然支持文件去重。合并完成主流程算基本跑通了。但真实网络环境不会这么顺利上传过程中随时可能中断、超时、甚至浏览器崩溃。接下来是断点续传和并发控制这部分。5. 断点续传和并发控制上传中断之后怎么恢复5.1 查询已上传分块check接口的设计断点续传的前提是前端重新上传时要先问一下服务端“这个文件已经有哪些分块了”。服务端只需遍历fileMd5目录下的.part文件返回存在的分块序号列表即可。private JSONObject handleCheck(String fileMd5) { JSONObject result new JSONObject(); JSONArray uploadedChunks new JSONArray(); File chunkDir new File(TEMP_DIR, fileMd5); if (chunkDir.exists()) { File[] files chunkDir.listFiles(); if (files ! null) { for (File f : files) { String name f.getName(); if (name.endsWith(.part)) { String idxStr name.substring(0, name.lastIndexOf(.part)); uploadedChunks.add(Integer.parseInt(idxStr)); } } } } result.put(uploadedChunks, uploadedChunks); result.put(code, 0); return result; }前端拿到已上传分块列表后只需要把未上传的分块挑出来重新传。如果用户上传到一半关闭了浏览器下次重新打开页面拖入同一个文件MD5一致前端就能直接跳过已完成的分块。对于几百MB的大文件来说这个体验和一次性上传是完全不同的。5.2 前端恢复与并发控制断点续传和并发控制在实现上是一对组合。我用的模型是维护一个待上传队列用“固定并发数”方式控制同时上传的分块数量每上传完一个分块就从队列里取下一个。这样既保证了不会一次性发出几十个请求把服务端打爆又能充分利用宽带。async function uploadWithConcurrency(fileMd5, chunks, uploadedSet, maxConcurrent) { var queue chunks.filter(function(chunk) { return !uploadedSet.has(chunk.index); }); var current 0; async function worker() { while (current queue.length) { var chunk queue[current]; await uploadChunk(fileMd5, chunk, chunks.length, fileName); } } var workers []; for (var i 0; i Math.min(maxConcurrent, queue.length); i) { workers.push(worker()); } await Promise.all(workers); }这里并发数怎么选我建议限制在2~4个。并发太多的话大量HTTP请求同时到达Servlet临时目录的I/O争抢会非常严重而且Tomcat的线程池也会被快速占满影响其他业务请求。2~3个并发在多数业务场景下已经足够关键是要保证单块的成功率而不是盲目追求同时传很多块。5.3 服务端并发与临时文件竞态分块上传天然是一个并发场景。多个分块同时到达Servlet同时写各自的临时文件这个没问题因为文件名不同。真正要小心的是合并和上传之间的竞态。比如最后一小块还在传输过程中前端的“合并”命令已经发出来服务端一看实际分块数不够直接返回错误前端提示“分块数量不足”用户就得重新传。为了避免这个问题我在服务端合并动作前加了一个synchronized锁锁粒度是fileMd5private void handleMergeWithLock(String fileMd5, String fileName, int totalChunks) throws IOException { synchronized (fileMd5.intern()) { handleMerge(fileMd5, fileName, totalChunks); } }合并完成后临时目录被清除即使前端又重复发了一次合并请求第二次进来时目录不存在会抛出异常。不过因为前端事先已经拿到成功的响应重复合并请求属于极小概率事件这个异常可作为日志记录不应直接展示给用户。5.4 已存在分块与断点续传的一个边界情况还有一种情况很容易被忽略用户第一次上传的文件A和第二次上传的文件B恰好MD5相同但文件内容不同——这是可能的虽然概率极低MD5碰撞或用户手动改过文件。如果纯靠fileMd5做目录B的某个分块上传时可能会复用到A留下的分块导致合并出来的文件损坏。我的处理方式是目录用fileMd5 _ fileName来命名文件名也参与分区。这样两个同名但内容不同的文件不会共享分块目录。虽然不是绝对防碰撞但工程上已经足够普通业务系统用不到密码学级别的哈希。断点续传做完之后整个上传主流程就完整了。但到这里还没结束因为在真实项目上线后我遇到了不少预料之外的坑。这些坑不亲自踩一遍光看理论很容易跳过去。6. 线上环境容易踩的五个坑6.1 Tomcat与前置代理的请求大小限制第一个坑就是开头提到的maxPostSize。如果用Servlet 3.0的Part接口分块上传时单个请求体实际上不到10MB正常不会触发这个限制。但如果你是先跑通代码再部到线上很容易忘记改前置代理的配置。Nginx默认的client_max_body_size是1MB所以分块上传时如果某块超过1MB就会被Nginx直接拒绝返回413错误。这个坑非常隐蔽因为本地开发环境没有Nginx一切正常一上测试环境就报413。需要把Nginx配置里的client_max_body_size调到适当值client_max_body_size 20m;注意这个值不能比单个分块大小小。如果分块是5MB建议设成20MB留一些余量给表单里的参数和文件头信息。6.2 Multipart请求体的编码问题Part接口的getParameter方法在处理multipart/form-data时如果请求体里有中文文件名而且Servlet没有设置正确的编码会出现文件名乱码最终合并出来的文件畸形甚至无法打开。解决方案是两处都要处理前端new FormData()时浏览器会自动用UTF-8编码后端在doPost里一开始就要调用req.setCharacterEncoding(UTF-8)。另外如果Tomcat的URIEncoding不是UTF-8建议在连接器上显式配置。6.3 临时目录不清空导致磁盘写满分块上传一个非常典型的运维问题如果用户上传了300MB的文件传到一半放弃临时目录里残留了一堆分块。如果这种情况多了磁盘迟早被写满。我是在项目里加了一个清理任务扫描/upload_temp目录下的文件如果文件的最后修改时间超过24小时且没有对应的上传进度就自动删除。更简单的做法是利用操作系统的cron定时任务find /data/upload_temp -type f -mtime 1 -delete find /data/upload_temp -type d -empty -delete这条命令在夜深人静的时候跑一遍能有效避免磁盘被残渣塞满。对于业务系统来说这个级别的清理策略已经足够。6.4 大文件MD5计算卡住浏览器UI前面提到过计算整个文件MD5的过程很耗时尤其是文件在1GB以上时浏览器端一次遍历可能持续几十秒。如果计算逻辑是同步的页面会冻结。解决思路是把MD5计算放到Web Worker里执行UI线程只负责显示“正在计算文件指纹xx%”。但是传统JSP项目里引入Web Worker需要单独写JS文件部署上有点麻烦。我的变通做法是MD5计算前弹出一个模态遮罩层提示用户文件较大需要等待计算完成后把遮罩去掉。虽然界面会暂时不可操作但至少有明确提示用户不会以为页面卡死了。如果你用的是支持增量MD5的脚本还可以每隔一段时间把进度渲染出来体验更好。这类方案很多具体选一个顺手的库即可。6.5 合并后文件损坏的排查路径如果合并出来的文件打不开、或者文件大小不对不要急着改代码先做三件事。第一检查临时目录里分块的数量是否等于预期。第二个检查每个.part文件的大小是否正常是不是存在0字节文件。第三重点检查合并代码里是否有“读取未完整分块”的竞态。我在排查过程中就遇到过两次分块上传时因为网络抖动某个分块只传了一半连接断开但Servlet已经创建了对应的.tmp文件异常发生后没有清理。由于文件后缀不是.part原本不会影响合并。但如果并发控制没做好合并线程把.tmp文件也当成分块读进去了就会出现“文件大小对但内容整个错位”的诡异现象。所以代码里合并时一定要只扫描.part结尾的文件这个约束需要贯穿始终。6.6 一个值得单独说明的小优化分块阈值判断文章最后我再分享一个偏实践的小优化。项目里我并没有让所有文件都走分块上传而是在前端代码里做了判断if (file.size 30 * 1024 * 1024) { // 小于30MB走普通表单上传 uploadSingleFile(file); } else { // 大于等于30MB走分块上传 uploadAllChunks(file); }这样处理的原因是很多内部系统日常上传的文档、图片本来就不大强行分块反而增加服务端合并操作的负担也拖慢上传速度。只有真正的大文件才进入分块流程。测试下来线上系统同时支持两类上传路径体验和稳定性都不错。总结下来大文件分块上传的核心不只是把文件切小块而是围绕“分块存储、完整校验、断点续传、并发控制”这四个环节做设计。每个环节都有各自的细节和边界情况把这些细节处理好这个功能才能在真实业务系统里稳定跑下去。