RandomAccessFile 不能直接创建稀疏文件空洞，因其跳过写入时会实际填充零字节而非留空洞；真正稀疏需系统调用如 fallocate 或 fsutil，Java 层需通过 exec 调用或 JNI 实现。
RandomAccessFile 能否直接创建稀疏文件空洞
不能。Java 的 RandomAccessFile 本身不感知底层文件系统是否支持稀疏文件，它写入时若跳过某段（比如用 seek(1024*1024*1024) 再写），在大多数操作系统（Linux ext4、XFS，Windows NTFS）上会**实际填充零字节**，导致磁盘立即被占满——这不是空洞，是“假稀疏”。真正稀疏行为依赖系统调用如 lseek(SEEK_HOLE) 或 SetFilePointerEx 配合 FILE_ATTRIBUTE_SPARSE，而 RandomAccessFile 没有暴露这些能力。
预分配大文件但不占磁盘空间的可行做法
必须绕过 RandomAccessFile 的写入逻辑，改用系统级预分配手段，再用 RandomAccessFile 后续随机写入：
- Linux 下用
fallocate -l 10G file.bin（需文件系统支持，ext4 ≥ 3.15、XFS 原生支持），或truncate -s 10G file.bin（更通用，但部分旧内核下仍可能分配块） - macOS 用
mkfile 10g file.bin - Windows 命令行不可靠，推荐 JNI 调用
CreateFile+DeviceIoControl(..., FSCTL_SET_SPARSE, ...)，或用PowerShell：fsutil file createnew file.bin 10737418240（不稀疏），配合fsutil sparse setflag file.bin（设为稀疏） - Java 层可封装
Runtime.getRuntime().exec(...)调用上述命令，但要注意路径空格、权限、返回码校验
多线程并发写入预分配文件的关键约束
即使文件已稀疏预分配，RandomAccessFile 多线程写仍需规避以下问题：
Web Accessibility (WCAG 2 AA))
下载
将 WCAG 2 AA 无障碍标准应用于设计系统、UI 组件和网页——通过可运行的验证器进行对比度计算，采用设计 token 模式使颜色天生可访问，设定排版和焦点状态规则，并提供语义检查清单。适用于构建或审查 UI。
- 每个线程必须严格限定写入范围，避免重叠：例如文件 10GB，4 线程各负责 2.5GB 区间，用
raf.seek(startOffset)定位后，只写write(byte[], 0, length)，且length不能超本段剩余空间 - 禁止使用
writeUTF、writeLong等带长度前缀或变长编码的方法——它们内部会先写长度字段，可能越界覆盖其他线程区域 - 不要依赖
getFilePointer()判断位置，它不是线程安全的；每个线程应自行维护当前偏移量变量 - 写入前建议对目标区间加
FileChannel.lock(start, size, false)，防止意外并发覆盖（虽然稀疏文件本身不因写入顺序出错，但业务逻辑可能要求强一致性）
为什么下载中断后恢复要检查空洞而非文件大小
稀疏文件的 length() 返回的是逻辑大小（比如 10GB），但 channel.size() 或 du -h 显示的物理占用可能只有几百 MB。因此恢复下载时：
- 不能只比对
file.length() == expectedSize判定完成 - 应逐段读取并校验 CRC32 或 MD5（比如每 1MB 一段），或用
FileChannel.map()映射后扫描非零页——但注意 mmap 在稀疏区域会按需分配内存，慎用 - 更实用的做法：记录每个线程已成功写入的字节数到独立元数据文件（如 JSON），重启时按该记录跳过已写区间
- Linux 下可用
filefrag -v file.bin查看实际分配的块，但 Java 无法直接调用，仅作调试参考
稀疏文件的“空”是文件系统的概念，Java 运行时看不见；你以为跳过的字节没写，其实只是没分配磁盘块——一旦某线程往空洞里写，系统才真正落盘，这个时机完全不可控。
