Users should create a new instance of SystemInfo and use the getters from this class to access the platform-specific hardware and software interfaces using the respective get*()
methods. The interfaces in oshi.hardware
and oshi.software.os
provide cross-platform functionality. See the main()
method of SystemInfoTest for sample code.
Methods return a "snapshot" of current levels. To display values which change over time, it is intended that users poll for information no more frequently than approximately every second. Disk and file system calls may incur some latency and should be polled less frequently. CPU usage calculation precision depends on the relation of the polling interval to both system clock tick granularity and the number of logical processors.
The interfaces and classes in oshi.hardware
and oshi.software.os
are considered the OSHI API and are guaranteed to be compatible with the same major version. Differences between major versions can be found in the UPGRADING.md document.
Most, if not all, of the platform-specific implementations of these APIs in lower level packages will remain the same, although it is not intended that users access platform-specific code, and some changes may occur between minor versions, most often in the number of arguments passed to constructors or platform-specific methods. Supporting code in the oshi.driver
and oshi.util
packages may,
rarely, change between minor versions, usually associated with organizing package structure or changing parsing methods for efficiency/consistency/ease of use.
Code in the platform-specific oshi.jna.*
packages is intended to be temporary and will be removed when that respective code is included in the JNA project.
OSHI 5.X is thread safe with the exceptions noted below. @Immutable
, @ThreadSafe
, and @NotThreadSafe
document
each class. The following classes are not thread-safe:
GlobalConfig
does not protect against multiple threads manipulating the configuration programmatically.
However, these methods are intended to be used by a single thread at startup in lieu of reading a configuration file.
OSHI gives no guarantees on re-reading changed configurations.getSessions()
method on the OperatingSystem
interface uses native code which is not thread safe. While OSHI's methods employ synchronization to coordinate access from its own threads, users are cautioned that other operating system code may access the same underlying data structures and produce unexpected results, particularly on servers with frequent new logins.
The oshi.os.unix.whoCommand
property may be set to parse the Posix-standard who
command in preference to the native implementation,
which may use reentrant code on some platforms.PerfCounterQueryHandler
class is not thread-safe but is only internally used in single-thread contexts,
and is not intended for user use.Earlier versions do not guarantee thread safety, but as of version 4.6.0, intended use is thread safe.
Classes with setters on them are obviously not thread-safe unless the use of the setters is synchronized across threads.
In the case of the HWDiskStore
, this synchronization must extend to the HWPartition
objects
associated with that disk store.
Prior to version 4.1.0, there is no guarantee of thread safety and it should not be assumed.
OSHI 3.x is compatible with Java 7, but will not see any added features.
OSHI 4.x and later require minimum Java 8 compatibility. This minimum level will be retained through at least 2026.
In the future, OSHI may include a new artifact targeting JDK 17 and leveraging JPMS, while maintaining feature parity with the JDK 8 version.
OSHI has been implemented and tested on the following systems. Some features may work on earlier versions.
NoClassDefFound
errors?OSHI uses the latest version of JNA, which may conflict with other dependencies your project (or its parent) includes. If you experience issues with NoClassDefFound
errors for JNA artifacts, consider one or more of the following steps to resolve the conflict:
jna
and jna-platform
artifacts) as a dependencyjna.version
propertyBoth OSHI and Hyperic's SIGAR (System Information Gatherer and Reporter) provide cross-platform operating system and hardware information, and are both used to support distributed system monitoring and reporting, among other use cases. The OSHI project was started, and development continues, to overcome specific shortcomings in SIGAR for some use cases. OSHI does have feature parity with nearly all SIGAR functions. Key differences include:
Yes, most of the Linux code works here and other Pi-specific code has been implemented but has seen limited testing. As the developers do not have a Pi to test on, users reporting issues should be prepared to help test solutions.
Maybe! If you can contribute all the code to implement the feature, it will almost certainly be added. Even if you can't code but can provide pointers to where the information can be found cross-platform, your feature has a good chance. Otherwise, you can always submit an issue to ask, but are at the mercy of the developers' time, enthusiasm level, and the availability of documentation for the feature.
此处可能存在不合适展示的内容,页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容,可点击提交进行申诉,我们将尽快为您处理。