如何在 Java 中通过 File.getFreeSpace() 获取磁盘分区的剩余可用空间-java教程-PHP中文网

getusablespace()才是获取当前进程实际可用空间的正确api；getfreespace()仅返回理论剩余空间，受预留块、配额等影响，而getusablespace()已扣除这些限制，适用于磁盘告警等真实场景。

如何在 java 中通过 file.getfreespace() 获取磁盘分区的剩余可用空间

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）

示例：

Gradle 9.8.0

下载

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 处理。