如何运用RandomAccessFile的文件空洞特性，实现超大文件断点续传的预分配策略？

本文共计890个文字，预计阅读时间需要4分钟。

RandomAccessFile不直接创建或管理稀疏文件（Sparse File），它仅提供随机读写能力。操作系统是否实际分配磁盘空间取决于其如何处理写入操作。对于决定写入行为，操作系统通常将文件逻辑长度设置为最终大小（如通过setLength()），然后按需写入数据块。在多数现代文件系统中（如ext4、NTFS、XFS），未写入区域不会占用物理磁盘空间，从而形成空洞。这正是断点续传中高效预分配的关键。

用 setLength() 预伸展文件，制造逻辑空洞

下载开始前，若已知目标文件总大小（例如从 HTTP Content-Length 或服务端元数据获取），可立即调用 setLength(totalSize)。这会将文件逻辑长度设为指定值，但不写入任何字节——文件系统仅更新 inode 中的大小字段，不分配数据块。

• 即使 totalSize 是 100GB，setLength(100L * 1024 * 1024 * 1024) 几乎瞬时完成，且不占磁盘空间
• 后续对任意偏移位置（如 50GB 处）写入数据时，文件系统才按需分配该区域的物理块
• 注意：必须确保文件已存在且可写；若文件不存在，需先创建空文件再调用 setLength

配合 Range 请求，精准写入已下载片段

HTTP 断点续传依赖 Range 请求头（如 Range: bytes=1024-2047）。客户端记录每个成功写入的字节范围（offset + length），每次恢复下载时，跳过已写区域，只请求剩余区间。

• 用 raf.seek(offset) 定位到目标起始位置，再调用 raf.write(buffer, 0, len) 写入数据
• 无需清空或覆盖已有内容——空洞区域天然“空白”，已写区域保持不变
• 建议每次写入后调用 raf.getChannel().force(false) 确保数据落盘（尤其重要段落）

校验与完整性保障不能依赖空洞

空洞只是节省空间的机制，不提供数据一致性保护。断点续传必须独立维护校验逻辑：

• 保存已下载的 offset-length 映射（如 JSON 文件或数据库），而非依赖文件内容判断“哪里写了”
• 下载完成前，对每个写入块做 MD5/SHA256 校验（服务端应提供分块哈希或整体哈希）
• 重启时，先读取本地记录的已下载范围，再向服务端发起 HEAD 或自定义校验接口确认有效性

跨平台与文件系统注意事项

稀疏特性由 OS 和文件系统共同决定，Java 层无感知：

• Linux（ext4/xfs）和 Windows（NTFS）原生支持稀疏文件，setLength() 行为符合预期
• macOS APFS 对稀疏支持有限，setLength() 可能触发实际零填充（导致磁盘爆满），建议下载前检查 df -h 并预留足够空间
• 容器或网络存储（如 NFS、某些云盘）可能禁用稀疏特性，此时 setLength() 会强制分配全量空间——务必测试实际磁盘占用