randomaccessfile写空洞文件不真正写磁盘是因为seek后write仅标记元数据为稀疏文件，实际空间按需分配；预分配需单次原子完成，多线程须各自独立raf实例并用"rws"模式，恢复依赖magic标记而非文件长度。
RandomAccessFile 写空洞文件时为什么不会真正写磁盘
因为 RandomAccessFile 调用 seek() 跳到远端再 write() 一个字节，操作系统（尤其 ext4/xfs/NTFS）会标记中间区域为“未分配”，只记录元数据——这就是稀疏文件（sparse file）。实际磁盘空间等到真正写入数据才分配。
这对断点续传预分配极有用：你不需要循环写 0 填满整个文件，seek() 到末尾 + write(0) 一行就搞定几十 GB 的“占位”。但注意：必须确保后续写入是随机位置落盘，且不触发自动填充（比如某些 JVM 或文件系统在 close 前强制补零）。
- Linux 下用
ls -lsh查看，第一列是实际占用块数，第二列才是逻辑大小；若远小于后者，说明空洞生效 - Windows 上需用
fsutil sparse setflag显式开启稀疏支持，否则RandomAccessFile可能静默填零 - JVM 本身不干预，但部分 JDK 版本（如早期 OpenJDK 8u）在
close()时对未写区域做隐式 zero-fill，建议用jdk-11.0.2+或手动验证
多线程写入前必须先完成预分配，否则会竞争导致文件损坏
多个线程直接 RandomAccessFile 打开同一文件并各自 seek()+write()，如果文件还没预分配到目标长度，某线程写到最后触发扩容，可能引发文件系统重映射，其他线程的 seek() 地址瞬间失效或覆盖错位。
所以预分配必须是原子、单次、线程安全的前置动作。不要让每个线程自己判断“是否要分配”。
- 用一个独立线程或主线程调用
raf.seek(fileSize - 1); raf.write(new byte[]{0});完成预分配 - 预分配后，所有工作线程都以
"rws"模式打开（而非"rw"），确保每次write()立即落盘，避免缓存不一致 - 绝对不要在多线程中用
raf.length()判断当前大小来决定写位置——它可能返回旧值，尤其在扩容瞬间
分块写入时 seek() + write() 的顺序和异常处理很关键
每个线程负责一个固定区间（如 [start, end)），必须严格按“先 seek(start)，再 write(buf, offset, len)”执行。中间不能穿插其他线程的 seek()，否则指针偏移错乱。
通过 yarn-threads-cli 与 Threads（Meta）交互。当用户想要阅读首页动态、点赞、收藏的帖子或特定帖子时使用；查看...
RandomAccessFile 不是线程安全的，即使文件已预分配，多个线程共用同一个 raf 实例必然出问题。必须每个线程持有一个独立 raf 实例（相同文件路径、相同 "rws" 模式）。
- 每次
write()后检查返回值，必须等于预期长度，否则抛异常终止——write()返回 -1 表示失败，但不会自动重试 - 写入失败时，不能简单跳过该块；要记录失败偏移，并在恢复时重新调度，否则产生空洞（非预期的、不可读的 0 区域）
- 避免用
writeFully()：它内部循环调用write()，但异常中断后无法知道已写多少，难以精确恢复
断点续传恢复时怎么安全判断哪些块已完成
不能依赖文件长度（raf.length()），因为预分配后它恒等于目标大小；也不能靠校验和——太慢。实用做法是维护一个外部状态文件（如 JSON），记录每个分块的 offset 和 status: "done" | "failed" | "pending"。
更轻量的做法是：每个线程写完一块后，在对应位置额外写 4 字节 magic（如 0xDEADBEEF），恢复时用另一个 RandomAccessFile 以 "r" 模式快速扫描这些 magic 标记位。
- magic 必须写在块数据之后（如 offset + blockLen），且长度固定，避免和业务数据混淆
- 扫描时用
raf.seek(offset + blockLen); int flag = raf.readInt();，比读整块快两个数量级 - 注意字节序：Java 默认大端，确保写入和读取一致；推荐用
ByteBuffer.order(ByteOrder.LITTLE_ENDIAN)统一转小端防歧义
空洞预分配本身不保存业务语义，所有“哪里写完了”的判断，都得靠外部状态或显式标记。这点容易被忽略——以为文件长度够了就等于数据全了。
