OSHI 7.6 评测：Java 系统信息库的 JNA 与 FFM 双轨选择

它解决什么问题，为谁而写

Java 程序要获取操作系统版本、CPU 使用率、内存占用、磁盘分区、传感器温度这类信息，传统做法是调用 Runtime.exec 解析命令输出，或者写 JNI 绑定 C 库。前者脆弱，后者繁琐。OSHI 用 Java 封装了这些底层调用，提供统一的跨平台 API。它的目标用户是那些需要监控、诊断或资源管理功能的 Java 开发者，尤其是桌面工具、运维脚本或性能分析器。OSHI 不要求安装额外的原生库，这一点与很多需要单独部署 .so 或 .dll 的库不同。它覆盖 Windows、macOS、Linux（含 Android）以及 AIX、FreeBSD、Solaris 等 UNIX 变体，但注意 Android 需要额外配置 JNA 的 AAR 包，这算是一个小门槛。

双轨原生访问：JNA 与 FFM 的取舍

OSHI 7.6 提供两种原生访问实现。oshi-core 基于 JNA，支持 JDK 8 以上，是长期稳定的选择。oshi-core-ffm 使用 JDK 25 引入的 Foreign Function & Memory API，需要 JDK 25+。两者共享 oshi-common 中的同一套接口，所以业务代码无需改动。关键差异在于运行时选择：如果两个 jar 都在 classpath 上，OSHI 会自动优先选 FFM（前提是 JDK 25+），否则回退到 JNA。这意味着你可以同时引入两个实现，让库在旧 JDK 上自动降级。但要注意，FFM 实现需要 --enable-native-access 标志，而 JNA 也需要类似处理，否则 JDK 会打印警告。OSHI 还提供了一个纯 Java 的 nativefree 实现，放在 oshi-common 里，只读取 procfs、sysfs 和 sysctl，不需要任何原生访问，因此没有警告。这个实现只覆盖 Linux 和 NetBSD，功能范围显然更窄。

从 SystemInfo 到硬件信息的调用链

使用 OSHI 的入口是 SystemInfoProvider 接口。通过 SystemInfoFactory.create() 可以自动选择最佳实现，也可以直接实例化对应的 SystemInfo 类。拿到实例后，调用 getHardware() 获取 HardwareAbstractionLayer，再通过 getProcessor() 得到 CentralProcessor，或者调用 getOperatingSystem() 获取操作系统信息。这套分层结构在 README 中有明确示例。底层数据来源因平台而异，但 OSHI 统一了返回类型，比如 CPU 的 tick 计数器、内存的 used/available、磁盘的 reads/writes。这种抽象让跨平台代码看起来一致，但代价是某些平台特有的字段可能缺失，比如传感器的支持就注明只在部分硬件上可用。

实际运行：Maven 依赖与配置要点

引入 OSHI 很简单，在 Maven 或 Gradle 中添加 com.github.oshi:oshi-core:7.6.0 即可，传递依赖会自动解析。如果你手动管理 jar，可以从 GitHub release 的 oshi-dist zip 中获取全部依赖。对于 Windows 传感器，README 建议添加可选的 jLibreHardwareMonitor 依赖，但要注意其二进制 DLL 采用 MPL 2.0 许可，这与 OSHI 的 MIT 许可不同，属于许可证上的额外负担。运行示例代码时，可以克隆仓库并执行 SystemInfoTest 的 main 方法，它会打印完整的系统报告。配置方面，oshio.properties 文件可调整默认行为，也可以通过 GlobalConfig 类或 Java System Properties 在启动时设置。文档明确警告：配置不是线程安全的，OSHI 不保证运行期间重新读取配置，所以必须在启动阶段完成设置。

功能覆盖与边界：哪些信息拿不到

OSHI 的功能列表很长，包括 CPU 物理核心和逻辑线程、NUMA 节点、缓存、进程的命令行参数、文件系统挂载点、网络接口带宽、电池状态、USB 设备、显示器 EDID 信息、GPU 利用率、传感器温度等。但列表也暗示了边界：传感器只在部分硬件上可用，GPU 信息可能依赖特定驱动。container 资源限制和用量支持 cgroup v1/v2，这对容器化部署有用，但要注意它只覆盖 Linux。一个明显的限制是 nativefree 实现只支持 Linux 和 NetBSD，如果你在 macOS 上只用 oshi-common，将无法工作。另一个失败模式是 JNA 的 NoClassDefFoundError 或 NoSuchMethodError，FAQ 中有专门的解决方案，但说明这类问题确实会发生，通常与 JNA 版本冲突有关。

替代方案：与 SIGAR 和系统命令的对比

一个常见的替代方案是 Hyperic SIGAR，它也曾是获取系统信息的流行 Java 库，但 SIGAR 需要为每个平台编译原生库，并且维护状态不佳。OSHI 的优势在于纯 Java 依赖，通过 JNA 动态调用系统 API，免去了平台特定的二进制文件。另一种做法是直接执行系统命令，比如读取 /proc/stat 或调用 wmic，这种方式零依赖但解析逻辑需要自己写，且不同平台命令输出格式差异大。OSHI 的 nativefree 实现实际上就是这类命令的封装，但它只覆盖 Linux 和 NetBSD。如果你只需要 Linux 上的几个指标，自己写脚本可能更轻量，但若要跨平台且统一 API，OSHI 更合适。

维护成本与升级路径

OSHI 的发布节奏看起来活跃，7.6.0 在 2026 年 8 月发布，紧跟着 7.5.0 和 7.4.4。这意味着修复和功能更新较快，但升级时需要注意 API 变化。README 提到有 UPGRADING.md 文件，说明项目重视迁移指南。许可证是 MIT，宽松且商业友好，但可选的 jLibreHardwareMonitor 依赖引入了 MPL 2.0，如果你在商业产品中使用传感器功能，需要评估该许可证的条款。维护成本主要体现在两方面：一是跟踪 OSHI 版本更新，二是处理 JNA 与你的其他依赖之间的版本冲突。由于配置不热加载，任何配置变更都需要重启应用，这在生产环境中是一个操作成本。

编辑结论

OSHI 适合需要在 Windows、macOS、Linux 及多种 UNIX 变体上获取 CPU、内存、磁盘、传感器等信息的 Java 开发者，尤其是那些不想编写 JNI 代码或依赖额外原生库的项目。若你仍使用 JDK 8 到 24，应选择 oshi-core（JNA 实现），它支持 JDK 8+；若已升级到 JDK 25+，可改用 oshi-core-ffm 以获得更现代的原生访问方式。不应采用 OSHI 的场景包括：仅需 Linux 或 NetBSD 的简单指标且不想处理原生访问警告，此时可只用 oshi-common 的 nativefree 实现；或者你需要 Windows 传感器数据，但不愿接受 jLibreHardwareMonitor 的 MPL 2.0 许可证。首次采用前，请确认你的目标平台是否在支持列表内（如 Android 需额外配置 JNA AAR），并检查 oshi.properties 中的默认配置是否满足你的轮询频率需求，因为配置在运行期间不会重新读取。

官方来源

1. Official documentation
2. Official README
3. Project repository
4. Release notes