-
Notifications
You must be signed in to change notification settings - Fork 0
FAQ
- Do I need to use a try-with-resources statement for LazySystemMonitor and BackgroundSystemMonitor?
- All usage metrics should be supported on my JVM/Platform, but CpuUsage/MemoryUsage are still returning negative values?
- Why does LazySystemMonitor report incorrect aggregate statistics?
- Why are negative values sometimes reported for CPU usage metrics even though it's supported on my platform?
- Why is BackgroundSystemMonitor always returning negative values for all CPU/memory usage metrics?
- You are using com.sun.management.OperatingSystemMXBean, isn't that an internal API that should not be relied on?
LazySystemMonitor doesn't hold any Closeable resources, so try-with-resources isn't required—but using it is still good practice for consistency with all Closeable implementations. BackgroundSystemMonitor runs a background daemon thread and should be properly closed by calling close() or stop() when finished. The SystemMonitor.close() method is declared to never throw exceptions which should make it easier to use in code paths where a try-with-resources statement isn't practical.
All usage metrics should be supported on my JVM/Platform, but CpuUsage/MemoryUsage are still returning negative values?
This typically happens when the metrics haven't been initialized yet. The underlying system needs time to collect baseline measurements. This is most commonly seen on the very first call to retrieve usage metrics.
Remember that LazySystemMonitor updates metrics on demand (on each call to getCpuUsage or getMemoryUsage). If you call these methods infrequently, your aggregate statistics will be inaccurate. Consider using BackgroundSystemMonitor instead.
Why are negative values sometimes reported for CPU usage metrics even though it's supported on my platform?
This typically happens when the metrics haven't been initialized yet. The underlying system needs time to collect baseline measurements before it can calculate usage statistics. This is most commonly seen if the very first call to retrieve usage metrics occurs immediately after the monitor is created.
You probably forgot to start() it.
You are using com.sun.management.OperatingSystemMXBean, isn't that an internal API that should not be relied on?
You are right that it is not part of the Public Java API. Practically speaking I have not seen a JVM where it is not available.
In Java 9 it was made accessible in the jdk.management package.
In either case, if it is not available there is a fallback mechanism to calculate process CPU metrics, while system-wide CPU metrics will be unavailable.