文件空洞是位置跳转后写入不连续的必然结果，仅当position超出末尾且执行write时触发；防范关键在于控制其出现时机、可接受性及副作用，而非单纯避免。
高频乱序覆写时，文件空洞不是“意外”，而是位置跳转 + 写入不连续的必然结果。防范的关键不是避免它出现，而是控制它何时出现、是否可接受、以及如何避免副作用。
明确空洞产生的条件
空洞只在以下两个动作同时发生时产生：
- 调用 position(long) 把写入位置设到当前文件末尾之后（比如当前文件长 1KB，却 position(5KB)）
- 紧接着调用 write(ByteBuffer, position) 或普通 write()（此时通道会自动扩展文件至该位置，并用 0 填充中间空白）
注意：仅 position 超出末尾不会立刻生成空洞；只有实际执行写操作才会触发文件撑大和空洞创建。
按需选择写入方式，绕过空洞风险
若业务允许顺序写或预分配空间，优先避开空洞路径：
- 预分配文件大小：用 channel.truncate(expectedSize) 或先写满占位（如 ByteBuffer.allocate(size).put(new byte[size]).flip(); channel.write(buf)），确保后续所有 position 都落在已有范围内
- 始终使用带 position 参数的 write()：避免依赖通道当前 position，显式指定偏移量，配合预分配后就不再触发撑大逻辑
- 禁用“写即扩展”行为：不调用无参 write()，也不在未预分配时随意 position 到末尾外 —— 这是最直接的规避手段
接受空洞但控制其影响
某些场景（如日志分段、下载占位）本就需要空洞，此时重点是防止副作用：
- 复制/备份时保留空洞语义：用 transferTo/transferFrom（底层调用 sendfile/splice），它们能透传空洞；避免用 read+write 循环，否则空洞会被填 0，磁盘占用暴增
- 读取空洞区域返回 0 是正常行为：无需异常处理，但业务逻辑中若对“未写入区域”有特殊含义（如默认值、无效标记），应主动判断 position 是否越界，而非依赖读出的 0
- 监控实际磁盘占用：用 Files.getFileStore(path).getUsableSpace() 查物理空间，别只看 file.length()（它包含空洞）
多进程写入时额外注意锁与空洞协同
FileLock 是建议性锁，无法阻止其他进程绕过锁直接写入导致空洞错乱：
- 所有参与方必须统一使用 channel.lock()/tryLock()，且锁定范围覆盖待写区域（如
lock(pos, len, false)） - 避免用 RandomAccessFile("file", "rw") 后再 getChannel() —— 它默认可读写，若另一进程以只读打开，锁可能失效；推荐统一用 FileChannel.open(path, StandardOpenOption.READ, StandardOpenOption.WRITE)
- 写入前先 force(true) 确保元数据同步，减少因缓存导致的空洞视图不一致
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
