randomaccessfile.setlength() 是跨平台预分配文件空间的唯一可靠方式，调用内核接口瞬时扩展或截断逻辑长度，不写入数据、不触发i/o，但非稀疏文件创建；分布式场景须由主控节点统一调用，避免并发覆盖。
RandomAccessFile 本身不支持“文件空洞技术”——所谓空洞是 Linux ext4/xfs 等文件系统对 lseek()+write() 的底层行为抽象，Java 层无法控制，更谈不上在分布式下载中“利用”它来极速预占空间。
你看到的“文件大小变大但没写数据”，只是 length() 返回逻辑长度；实际磁盘占用（ls -lsh 第一列）通常立刻增长，因为 JVM 的 write() 会补零并触发预分配。这不是空洞，是真实落盘。
setLength() 是唯一可靠、跨平台的预分配方式
setLength(long newLength) 会直接调用 ftruncate()（Unix）或 SetEndOfFile()（Windows），让内核分配（或截断）到指定字节长度：
- ✅ 瞬时完成，无论目标大小（1GB 或 100GB 都毫秒级）
- ✅ 不写入任何字节，不触发 I/O，不填充零
- ✅ 所有主流 JVM 和文件系统都支持，行为一致
- ❌ 不是“稀疏文件创建”，而是“逻辑长度扩展”；后续首次写入仍可能触发块分配（但比逐字节写快几个数量级）
用法很简单：
RandomAccessFile raf = new RandomAccessFile("target.bin", "rw");
raf.setLength(20L * 1024 * 1024 * 1024); // 预占 20GB
raf.close();
注意：必须用 "rw" 模式；"rws" 或 "rwd" 会强制同步，反而拖慢。
分布式场景下，setLength() 必须由协调节点统一执行一次
多个节点并发调用 setLength() 到同一文件是安全的（POSIX 要求幂等），但没必要：
- 文件系统层面只认最终长度，多次调用等价于一次最大值调用
- 若各节点独立探测总大小再调用，可能因网络延迟/响应不一致导致长度被反复覆盖（如 A 写 10GB，B 后写 9GB，结果只剩 9GB）
正确做法：
- 由主控节点（或元数据服务）先 HEAD 请求获取
Content-Length - 主控节点单次调用
setLength(totalSize) - 其他 worker 节点跳过预分配，直接按分片 offset
seek()+write()
否则容易出现：worker 还没开始写，文件就被某个节点误设成 1KB，后续写入直接失败或截断。
为什么不要依赖“空洞”做断点续传校验
有人想靠 Files.getFileStore().supportsFileAttributeView("unix") + truncate() + seek() 检测“哪些块已写”，这是错的：
- Java 无接口读取稀疏文件的 hole 列表（
SEEK_HOLE/SEEK_DATA是 C 接口） -
raf.length()始终返回逻辑长度，和是否稀疏无关 - 即使文件系统支持稀疏，JVM 写入行为（尤其带缓冲的
write(byte[])）大概率已填充零，hole 早已消失
断点续传必须依赖外部元数据：.meta 文件记录每个分片的 start-end 及校验和，每次写完原子更新，不能靠文件系统“猜”。
预占空间只是第一步，真正防止错乱的，是每个线程独占 RandomAccessFile 实例 + 严格 seek(startOffset) + 分片元数据隔离。空洞不是捷径，是干扰项。
