Java多线程断点续传下载器实现方法

本文深入剖析了Java多线程环境下实现可靠断点续传下载器的核心技术难点与实战要点，涵盖服务端支持校验（Accept-Ranges/206响应）、Range请求头的正确构造与容错处理、RandomAccessFile多线程安全写入（独立实例+精准seek+句柄持久化）、断点状态的原子化持久化（元数据文件+文件锁+刷盘保障）、以及HttpURLConnection在连接复用、重定向和超时方面的隐蔽陷阱；每一步都直击生产环境常见崩溃、数据错位、静默损坏等“高危坑点”，为构建健壮、可恢复、真正可用的下载系统提供了经过验证的硬核解决方案。

Range 请求头怎么设才有效

服务端是否支持断点续传，不取决于你写了 Range，而取决于响应里有没有 Accept-Ranges: bytes 或至少返回了 206 Partial Content。很多 CDN、Nginx 默认关掉 Accept-Ranges，或者对动态资源（如 PHP/Java Servlet 生成的文件）直接忽略 Range —— 这时候你发了 Range: bytes=1000-，服务器仍可能返回 200 OK 全量内容，但你按偏移写入就会覆盖错位置。

实操建议：

• 发起请求前先 HEAD 一次，检查响应头是否含 Accept-Ranges: bytes；若无，别硬上断点，老老实实全量下载
• 用 HttpURLConnection 时，必须调用 setRequestProperty("Range", "bytes=" + start + "-" + end)，注意 end 可省略（表示“到结尾”），但不能写成 start-end 中间带空格或乱加单位
• 收到响应后立刻校验 getResponseCode()：必须是 206，否则说明服务端没按预期处理，此时应清空已写文件并降级为全量下载

RandomAccessFile 写入时如何避免文件错位

RandomAccessFile 不是线程安全的，多个线程共用一个实例写同一文件，极易出现字节覆盖、跳写、甚至 IOException: Invalid argument。更隐蔽的问题是：你用 seek(offset) 定位后，如果另一个线程也刚调用过 seek()，当前线程的写入位置就不可靠了。

实操建议：

• 每个下载线程必须持有独立的 RandomAccessFile 实例，打开模式用 "rw"，且不要复用或共享
• 写入前务必调用 raf.seek(offset)，且该 offset 必须与本次 Range 请求的起始字节完全一致——不能依赖上次写完的位置
• 写入完成后，**不要**调用 raf.close()，保持句柄打开直到整个下载完成；否则下次续传时文件可能被系统回收或重命名，导致 FileNotFoundException

多线程协作时如何同步断点状态

断点信息不能只存在内存里。JVM 崩溃、进程被 kill、机器断电，都会让内存中记录的已下载区间丢失。如果只靠文件长度判断“续传起点”，在多线程场景下会出错：因为各线程写入非原子，文件长度可能卡在中间状态（比如 A 线程刚写完 512B，B 线程还没开始，此时文件长度是 512，但实际有效数据只有 0–511，而你误以为 0–511 已完成，就从 512 开始分配新 Range，结果重复下载）。

实操建议：

• 用单独的临时文件（如 file.downloading.meta）持久化每一段的下载状态：start,end,status，status 可为 done / failed / pending
• 每次线程完成一段写入后，先 raf.getChannel().force(true) 刷盘，再更新元数据文件，并用 FileChannel.lock() 保证元数据写入原子性
• 启动续传时，不是读文件长度，而是解析元数据文件，合并所有 done 区间，再计算剩余缺口

HttpURLConnection 的连接复用与超时陷阱

HttpURLConnection 默认启用 Keep-Alive，但断点续传中频繁新建连接（尤其是分块多线程）容易触发连接池耗尽或服务端主动断连。更麻烦的是：它对 Range 请求的缓存行为不透明，某些 JDK 版本会在重定向后丢弃 Range 头，导致后续请求变成全量。

实操建议：

• 显式关闭连接复用：conn.setRequestProperty("Connection", "close")，避免长连接状态干扰
• 设置合理超时：setConnectTimeout(10_000) 和 setReadTimeout(30_000)，尤其 readTimeout 要大于单次最大分块传输时间，否则可能中断在半途，又没触发异常捕获逻辑
• 遇到 HTTP 302 重定向时，HttpURLConnection 默认自动跳转，但不会携带原请求的 Range 头——必须手动拦截 getHeaderFields()，提取 Location，再新建连接并重新设置 Range

最易被忽略的一点：RandomAccessFile 的 seek() 是逻辑偏移，不校验物理文件大小；如果元数据记录错误或服务端返回内容少于预期（比如网络截断），写入时会静默填充 \0 到目标位置，导致文件损坏且难以排查。

到这里，我们也就讲完了《Java多线程断点续传下载器实现方法》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！