getUsableSpace()才是获取当前进程实际可用空间的正确API；getFreeSpace()仅返回理论剩余空间，受预留块、配额等影响，而getUsableSpace()已扣除这些限制，适用于磁盘告警等真实场景。
File.getFreeSpace() 返回的是“未被本用户占用但操作系统允许当前进程使用的字节数”，不是磁盘剩余总空间，也不是“人眼可见的可用空间”。它可能比 df -h 显示的小，也可能大——取决于文件系统预留块、挂载选项和用户配额。
为什么 getFreeSpace() 和 df 结果不一致
常见现象：Java 里调用 file.getFreeSpace() 得到的值，比终端执行 df -h /path 显示的 “Avail” 列小几十 GB。这不是 bug，而是语义差异：
-
getFreeSpace()只返回当前运行 Java 进程的**有效可用字节**，受 Linux 的 root reserved blocks（默认 5%）影响——即使你是普通用户，这部分空间也不计入返回值 - 如果分区启用了配额（quota），且当前用户已接近限额，
getFreeSpace()会提前反映该限制；而df默认显示的是 superuser 视角下的可用空间（除非加-B或--total） - 某些文件系统（如 XFS、Btrfs）对“free space”的定义更复杂，
getFreeSpace()底层调用statvfs()，但 JVM 对其f_bavail字段的解释是严格按 POSIX 的“非特权用户可用块数”
正确获取“用户实际能写的剩余空间”的写法
别只依赖 getFreeSpace()。应结合 getUsableSpace() ——它才是你真正该用的 API：
-
getFreeSpace()：所有用户（含 root）理论上可分配的剩余空间（不含 reserved blocks） -
getUsableSpace()：**当前 JVM 进程用户**实际能创建文件的空间，已扣除 reserved blocks、配额、ACL 限制等 -
getTotalSpace()：整个分区总大小（不含元数据开销，但含 reserved blocks）
示例：
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
立即学习“Java免费学习笔记（深入）”；
File root = new File("/");
System.out.println("Free: " + root.getFreeSpace() / 1024.0 / 1024 / 1024 + " GB");
System.out.println("Usable: " + root.getUsableSpace() / 1024.0 / 1024 / 1024 + " GB");
System.out.println("Total: " + root.getTotalSpace() / 1024.0 / 1024 / 1024 + " GB");
多数监控或磁盘告警逻辑，应该基于 getUsableSpace() 做阈值判断。
跨平台兼容性与权限陷阱
在 Windows 上，getFreeSpace() 和 getUsableSpace() 行为基本一致（无 reserved blocks 概念），但仍有坑：
- 若 Java 进程以低完整性级别运行（例如被 IE 模式或某些沙箱启动），即使磁盘有空间，
getUsableSpace()也可能返回 0 —— 此时需检查进程 token 权限，而非磁盘本身 - 在容器环境（Docker/Podman）中，如果挂载时用了
size=限制（如 overlay2 的overlay.size），getUsableSpace()反映的是容器层配额，不是宿主机磁盘真实值 - Android 上（API 29+），应用默认无法访问外部存储根目录，
new File("/sdcard").getUsableSpace()可能抛SecurityException或返回 0，必须用Context.getExternalFilesDir()获取沙箱路径再查
最常被忽略的一点：这些方法返回 long，最大支持约 8EB。但如果你在 32 位 JVM 或极老版本（Java 6u23 之前）上运行，getUsableSpace() 在大于 2TB 的卷上可能溢出为负值——务必检查返回值是否 ≥ 0，否则直接当作 0 处理。
