FileChannel.size() 返回逻辑文件大小而非物理占用空间，其值等于文件末尾偏移量，与稀疏文件的实际磁盘占用无关；获取物理大小需用Files.getAttribute("unix:blocks")（Unix）或平台特定API（Windows）。
FileChannel.size() 返回的是逻辑文件大小，不是物理占用空间
FileChannel.size() 读取的是文件的逻辑长度（即从开头到末尾字节偏移量），它不关心底层是否稀疏、是否被截断、是否有未写入的空洞。比如用 channel.truncate(1024) 缩小后，size() 立即返回 1024；但用 channel.position(1000000).write(...) 跳过中间写入，生成稀疏文件时，size() 仍会返回远大于实际磁盘占用的值。
如果你要查“这个文件在磁盘上真正占了多少字节”，FileChannel 本身不提供该能力——它抽象的是字节流视图，不是文件系统元数据。
获取物理大小得绕回 File 或 Path API
Java 中唯一可靠获取物理磁盘占用（即文件系统实际分配的块总和）的方式，是调用 Files.getAttribute() 查询 "unix:blocks"（Linux/macOS）或依赖 File.length() + 文件系统特性推断（Windows 下基本等同于逻辑大小）。但注意：File.length() 和 FileChannel.size() 在绝大多数场景下数值一致，因为它们都读取同一内核 inode 的 st_size 字段。
- Linux/macOS：用
Files.getAttribute(path, "unix:blocks")，再乘以512（POSIX 块单位），得到近似物理字节数（注意：不是精确扇区数，而是分配的 512B 块数） - Windows：没有标准跨 JVM 的物理块查询方式；
length()和size()都只反映逻辑大小；若需真实占用，需调用win32.GetDiskFreeSpaceEx（通过 JNA/JNI），或接受它≈逻辑大小 - 通用兜底：对普通非稀疏文件，
channel.size()就是你能安全依赖的“有效数据长度”
稀疏文件场景下 size() 和 du 输出差异明显
当你用 FileChannel 跳跃写入（如 position(1024 * 1024).write(ByteBuffer.wrap(data))），Linux 可能创建稀疏文件。此时 du -h file 显示几 KB，而 ls -l 或 channel.size() 显示 1MB+。这是正常行为，不代表 size() 错了——它正确反映了“你写到了多远”。
验证方法：
dd if=/dev/zero of=sparse bs=1 seek=1048576 count=1 java -c "System.out.println(new java.io.RandomAccessFile(\"sparse\", \"r\").getChannel().size());"
输出 1048577，而 du -b sparse 很可能只显示 1 或 512 —— 这就是逻辑 vs 物理的典型撕裂点。
别试图用 FileChannel 自身获取 block count
FileChannel 没有 getBlockCount()、getPhysicalSize() 或类似方法。它的设计目标是高效字节传输，不是暴露文件系统细节。试图通过 map() + force() + position() 组合推算物理大小，不仅不可靠，还会引入竞态和性能开销。
真正需要物理大小时，请明确使用路径并切换到 Files 或平台特定 API。混淆逻辑长度和磁盘占用，常导致日志误报、配额计算错误、备份策略失效——这些坑往往在大文件或容器环境中才突然暴露。
