大文件多线程下载技巧：利用文件空洞实现

本文澄清了一个在Java多线程大文件下载中广泛存在的技术误解：RandomAccessFile并不真正支持“文件空洞”以节省磁盘空间，其seek后write会强制填充零字节并真实分配存储（除非底层文件系统、内核与JVM特殊配合，但Java层完全不可控）；真正的断点续传和高效下载依赖于严谨的Range请求校验（严格判断206响应）、每个线程独占RandomAccessFile实例、原子化offset持久化、分片完整性校验，而非依赖虚幻的“空洞”机制——抓住这些底层可控的关键点，才能构建稳定、高性能、可恢复的多线程下载方案。

直接说结论：RandomAccessFile 本身不支持“文件空洞”技术，所谓“空洞”是 Linux 文件系统（如 ext4）对 lseek + write 的底层行为抽象，Java 的 RandomAccessFile 在调用 seek() 后写入数据，**会真实分配磁盘空间并填充零字节（除非文件系统+内核+JVM 配合启用稀疏文件支持，但 Java 层无控制权）**。所以“用空洞节省磁盘”在 Java 多线程下载中是个常见误解。

为什么 seek() 后 write() 不产生真正空洞

Java 的 RandomAccessFile.seek(long pos) 底层调用的是 POSIX lseek()，但后续 write()（如 write(byte[] b)）触发的是同步写入——JVM 会把从当前位置到写入起始点之间的空白全部补零（或触发文件系统预分配），尤其在 Windows 和多数 Linux 默认挂载选项下，df 显示的已用空间会立刻增长。你看到的“文件大小变大但没写满”，其实是 length() 返回逻辑长度，不是实际稀疏块数。

• 验证方式：下载中途用 ls -lsh file（Linux/macOS）看“disk usage”列，通常和 ls -l 显示大小一致
• FileChannel.map() + MS_SYNC 或 MS_INVALIDATE 也绕不开这个限制
• 真正稀疏行为需手动调用 FileChannel.truncate() + Files.getFileStore().supportsFileAttributeView("unix") 判断，且仅限 Unix-like 系统

多线程写入必须用 "rw" 模式且每个线程独占 RandomAccessFile 实例

多个线程共用一个 RandomAccessFile 对象会导致 seek() 和 write() 互相覆盖指针位置，最终文件内容错乱。这是最常踩的坑。

• 每个线程必须 new 一个独立的 RandomAccessFile(file, "rw")，哪怕写入同一文件
• 构造时不能用 "rws" 或 "rwd"：它们强制落盘，严重拖慢吞吐，且对断点续传无实质帮助
• 写入前务必调用 raf.seek(startPos)，否则默认从 0 开始覆盖
• 注意 startPos 和 endPos 是字节偏移量，计算时用 long，避免 int 溢出（尤其 >2GB 文件）

Range 请求必须校验 206 Partial Content 且处理 Content-Length 不匹配

HTTP 分片下载不是简单加个 Range 头就行。服务端可能忽略、截断或返回 200 全量响应，导致线程写入位置错位。

• 必须检查 HttpURLConnection.getResponseCode() == 206，否则丢弃该线程数据并重试
• conn.getContentLength() 返回的是本次响应体长度，不是原始文件总长；总长应从首次 HEAD 请求的 Content-Length 获取
• 若服务端不支持 Range（如某些 CDN 或老旧 HTTP Server），Range 头会被静默忽略，响应码为 200，此时必须降级为单线程下载
• 不要依赖 Content-Range 响应头做边界校验——有些服务器不返回，或格式不标准（如缺失 /123456789）

断点续传的关键不在空洞，而在本地 offset 记录与 Range 对齐

所谓“续传”，本质是记录每个分片的已完成字节数。空洞技术对此毫无帮助；真正有效的是原子化更新 offset 文件 + 校验已写入段的 MD5（可选）。

• 为每个线程维护一个 .offset 文件（如 file.part0.offset），存当前已写入的 endPos
• 启动时读取 offset，设置 startPos = offset + 1，再发 Range: bytes=startPos-
• 写入成功后，用 FileChannel.force(true) 强刷 offset 文件，避免掉电丢失
• 合并阶段不依赖空洞，而是用 raf.length() 校验各分片是否写满，缺损则重下对应区间

真正需要关注的是：Range 支持度检测、线程安全的 seek+write 隔离、offset 持久化时机、以及服务端对 206 的一致性。空洞只是表象，别被它带偏了重点。

本篇关于《大文件多线程下载技巧：利用文件空洞实现》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！