- 3 minutes to read

Supported Garbage Collectors

This troubleshooting page explains how each garbage collector affects memory monitoring, GC pause behavior, and JVM tuning for the Nodinite JMX Monitoring Agent.

Supported Garbage Collectors

All standard JVM garbage collectors expose heap metrics via JMX. The Nodinite JMX Monitoring Agent supports monitoring JVMs using any of the following:

Garbage Collector JVM Flag Behavior Best For
G1GC (Garbage First) -XX:+UseG1GC Concurrent, low-pause, region-based Most modern workloads (JDK 9+ default)
ZGC -XX:+UseZGC Ultra-low pause, concurrent compacting Latency-sensitive applications (JDK 15+)
Shenandoah -XX:+UseShenandoahGC Concurrent evacuation, low pause OpenJDK builds (JDK 12+)
ParallelGC -XX:+UseParallelGC Throughput-focused, stop-the-world Batch processing workloads
SerialGC -XX:+UseSerialGC Single-threaded, simple Small JVMs, single-core environments
CMS -XX:+UseConcMarkSweepGC Concurrent mark-sweep Legacy JVMs (deprecated in JDK 9+)

Tip

Check which garbage collector your JVM uses by running: java -XX:+PrintFlagsFinal -version | grep UseG1GC

How Garbage Collection Affects Heap Monitoring

Heap memory usage fluctuates significantly during garbage collection. Understanding these patterns helps avoid false-positive alerts.

graph TD A["JVM Running - Heap Fills"] --> B{"Heap Usage > Threshold?"} B -->|Yes| C["GC Triggered"] B -->|No| A C --> D["Minor GC: Young Gen Collected"] D --> E{"Heap Still High?"} E -->|Yes| F["Major/Full GC: All Gen Collected"] E -->|No| A F --> G{"Heap Usage Drops?"} G -->|Yes| A G -->|No| H["OutOfMemoryError"] style A fill:#90EE90 style C fill:#FFD700 style F fill:#FF6B6B style H fill:#FF6B6B

Diagram: JVM garbage collection cycle showing how heap usage triggers minor and major GC before potentially reaching OutOfMemoryError.

Threshold Recommendations by Garbage Collector

GC Type Heap Volatility Recommended Warning Recommended Error
G1GC / ZGC / Shenandoah Low (concurrent GC keeps heap stable) 70% 80%
ParallelGC Medium (stop-the-world reduces heap in bursts) 75% 85%
SerialGC High (single-threaded GC, longer pauses) 65% 75%
CMS (legacy) Medium (concurrent but can fragment) 70% 80%

Note

The Duration setting in the Nodinite JMX Monitoring Agent configuration controls how long the heap must remain above threshold before triggering an alert. For GCs with high volatility (SerialGC, ParallelGC), increase the Duration to 120–300 seconds to avoid alerting during normal GC spikes.

The heap alert fires repeatedly during batch jobs. What should I do?

Increase the Duration threshold in the JMX Monitoring Agent Configuration to require the heap to remain elevated for longer before alerting. For batch jobs, 300–600 seconds is typical.

Why does heap usage jump to 95% then drop suddenly?

This is normal behavior for ParallelGC and SerialGC which perform stop-the-world collections. The heap fills until a major GC is triggered, then drops sharply. Use the Duration setting to filter these expected spikes.

GC overhead alerts are firing. What does this mean?

GC overhead alerts indicate the JVM is spending more than 98% of CPU time on garbage collection with less than 2% heap freed. This typically means a memory leak is present. Review application code for object accumulation patterns.

Next Step

Correlate Heap Spikes
Environment-Specific Thresholds

Heap Used vs Committed
JMX Troubleshooting Overview
JMX Monitoring Agent