本文目录导读：
- 什么是断点续传？为什么需要它？
- 核心技术原理：HTTP Range头与文件随机读写
- 单线程断点续传实现步骤（附代码）
- 多线程分段下载：提升速度的进阶方案
- 服务端如何支持断点续传？（Spring Boot示例）
- 常见问题与防坑指南
- 高频面试问答（Q&A）
Java实现断点续传案例：从原理到多线程下载实战（附完整代码）**
目录导读
- 什么是断点续传？为什么需要它？
- 核心技术原理：HTTP Range头与文件随机读写
- 单线程断点续传实现步骤（附代码）
- 多线程分段下载：提升速度的进阶方案
- 服务端如何支持断点续传？（Spring Boot示例）
- 常见问题与防坑指南
- 高频面试问答（Q&A）
什么是断点续传？为什么需要它？
断点续传（Resumable Download）指在文件下载过程中，因网络异常、用户暂停等原因中断后，再次下载时无需重新开始，而是从上次中断的位置继续下载剩余部分。
核心价值：
- 节省带宽与时间（尤其对大文件、弱网环境）。
- 提升用户体验,避免重复下载。
- 在分布式系统中,支持分块拉取与校验。
核心技术原理：HTTP Range头与文件随机读写
断点续传的关键是服务器支持HTTP Range请求头，客户端发送如 Range: bytes=1024-2047 的请求，服务器返回 206 Partial Content 状态码及对应字节区间数据。
Java侧实现依赖两个底层能力：
HttpURLConnection或OkHttp设置Range头。RandomAccessFile的seek()方法定位文件指针，实现随机写入。
单线程断点续传实现步骤（附代码）
步骤：
- 获取本地已下载字节数（例如通过
.tmp文件记录长度）。 - 设置
Range: bytes=已下载字节数-。 - 打开输入流,使用
RandomAccessFile.seek(已下载长度)，循环写入。 - 每次写入后更新进度（可写日志或更新缓存）。
// 核心代码示例
public static void downloadWithResume(String fileUrl, String localPath) {
File tmpFile = new File(localPath + ".tmp");
long existingLength = tmpFile.exists() ? tmpFile.length() : 0;
try {
URL url = new URL(fileUrl);
HttpURLConnection conn = (HttpURLConnection) url.openConnection();
conn.setRequestProperty("Range", "bytes=" + existingLength + "-");
int responseCode = conn.getResponseCode();
if (responseCode == HttpURLConnection.HTTP_PARTIAL) { // 206
try (RandomAccessFile raf = new RandomAccessFile(tmpFile, "rw");
InputStream is = conn.getInputStream()) {
raf.seek(existingLength);
byte[] buffer = new byte[1024 * 8];
int len;
while ((len = is.read(buffer)) != -1) {
raf.write(buffer, 0, len);
// 可在此回调进度
}
}
// 下载完成后，将tmpFile重命名为正式文件
tmpFile.renameTo(new File(localPath));
} else {
System.out.println("服务器不支持断点续传，完整下载");
// 省略完整下载逻辑...
}
} catch (IOException e) {
e.printStackTrace();
}
}
多线程分段下载：提升速度的进阶方案
单线程受限于服务器单个连接的带宽,多线程下载将文件分成N段，每段独立下载，最后合并。
实现思路：
- 发起
HEAD请求获取文件总长度totalLen。 - 指定线程数
threadCount，计算每段长度partLen = totalLen / threadCount。 - 每个线程负责
start = i * partLen到end = (i+1)*partLen -1（最后一个线程负责到末尾）。 - 每个线程使用独立的
RandomAccessFile（共享同一个文件对象，但各持有独立文件描述符）和Range头。 - 所有线程完成后,合并校验。
注意事项：
- 需要维护已下载状态,建议用
ConcurrentHashMap记录每段进度，支持崩溃恢复。 - 对动态变化文件不友好,应使用
ETag或Last-Modified校验一致性。
服务端如何支持断点续传？（Spring Boot示例）
服务端需处理Range请求头，返回正确的状态码和Content-Range。
@RestController
public class FileDownloadController {
@GetMapping("/download")
public ResponseEntity<Resource> download(@RequestHeader(value = "Range", required = false) String range) {
Path path = Paths.get("/data/test.zip");
long fileLength = path.toFile().length();
if (range == null) {
return ResponseEntity.ok()
.contentType(MediaType.APPLICATION_OCTET_STREAM)
.body(new FileSystemResource(file));
}
// 解析 Range: bytes=start-end
long start = Long.parseLong(range.split("=")[1].split("-")[0]);
long end = fileLength - 1;
long rangeLength = end - start + 1;
Resource resource = new InputStreamResource(Files.newInputStream(file, StandardOpenOption.READ).skip(start));
return ResponseEntity.status(HttpStatus.PARTIAL_CONTENT)
.header("Content-Range", "bytes " + start + "-" + end + "/" + fileLength)
.contentLength(rangeLength)
.body(resource);
}
}
常见问题与防坑指南
- ❌ 服务器返回200而非206：说明服务器忽略Range，此时需重新开始下载，或提醒用户更换服务。
- ❌ 临时文件的校验：下载完成后使用
MD5或SHA-1校验完整性。 - ❌ 磁盘空间不足：写入前检查剩余空间。
- ❌ 线程安全问题：多线程写入同一文件时，不同线程需操作不同区域，
RandomAccessFile本身是线程安全的，但seek+write需使用同一个锁，或为每个线程单独open文件句柄。 - ✅ 断点恢复策略：建议保存每段进度到
.progress配置文件，启动时加载，实现离线续传。
高频面试问答（Q&A）
Q1：断点续传如何知道当前已下载的字节数？
A：有三种方式：
- 检查本地临时文件大小（简单但不准确，若本地文件被截断）。
- 使用
Content-Length与本地文件长度对比。 - HTTP响应头中
Content-Range: bytes 已下载-总长度/总长度可精确获取（需记录响应头）。
Q2：如果服务器不支持Range头怎么办？
A：后端可返回200和完整文件，客户端检测responseCode == 200时，应决定是否放弃断点续传，直接重新下载；或者可以告知用户功能不可用。
Q3：多线程下载时如何合并文件？
A：各线程在各线程的偏移位置写入RandomAccessFile即可，因为各线程指定了明确的起始偏移量，最终所有线程写入完成后，整个文件自然会拼接完整，无需额外合并步骤。
Q4：如何避免重复下载同一块？
A：在客户端维护一个BitSet记录每个分块的完成状态，或者记录每个分块的字节长度，下载前跳过已完成的分块。
Q5：断点续传和分块下载的区别是什么？
A：断点续传侧重“从上次中断处继续”，仅关心未下载部分；分块下载侧重“并行加速”，将完整文件切成多块独立下载，实际项目中常常两者结合——多线程分块下载，每块内部支持断点续传。
结尾提示：
如果希望更快捷地实现断点续传，可借助现有库如Apache HttpClient的Range支持或开发中常用的FileDownloader框架，生产环境务必处理异常恢复与文件校验，保证数据的最终一致性。
