Helps you detecting Garbage Collector overflows before they trash, crash or overwhelm the JVM.
Maven dependency:
<dependency>
<groupId>com.github.honoluluhenk.gcmonitor</groupId>
<artifactId>gcmonitor</artifactId>
<version>1.0.5</version>
</dependency>
// this will collect data from an OpenJDK compatible JVM.
// Information of the last 5 GC collections will get
// used for overflow detection:
// If the last 3 memory usage measures are above 80%,
// detection will return an overflow.
GCOverflowDetector detector = new GCOverflowDetector(
new OpenJDKEventSource(),
new CollectionSizeExpiry<>(5),
new UsageAboveThreshold(3, 80)
);
// actually start monitoring
detector.start();
// do some detection.
Overflow overflow = detector.detect();
// detect() may be called asynchronously and also multiple times.
// This allows implementing an external healthcheck easily.
if (overflow.getStatus() == Status.OVERFLOW) {
System.out.println("Got overflow, reason: " + overflow.getReason());
}
// cleanup
detector.stop();The detector also supports re-use by calling detector.start() and detector.stop() repeatedly.
Class: GCOverflowDetector
This is the main workhorse.
Tries to detect JVM memory overflows before they actually happen.
Uses Event Sources for memory usage data acquisition, Expiries for data removal and Detectors for the actual detection of memory overflows.
Class: OpenJDKEventSource
Supports OpenJDK and compatible (Oracle, IBM, ...) JVMs.
Class: CollectionSizeExpiry
Retains a maximum amount of measures. Older measures get expired first.
Class: DurationExpiry
Keeps measures that are younger than some TemporalAmount.
Class: NullExpiry
Never expires anything. Mainly used for development since never expiring anything means a memory leak!
Class: UsageAboveThreshold
Takes N (1 <= N <= Integer.MAX_VALUE) memory usage readings. If all of these readings are above a threshold, an overflow is detected.
Class: AverageUsageAboveThreshold
Works like UsageAboveThreshold but averages the memory usage over N memory usage readings.
If the averaged usage is above a threshold, an overflow is detected.
This library requires the use of JDK internal classes in the package com.sun.management.
Include the a system-dependency to the aforementioned package in a jboss-deployment-structure.xml file in your
deployment.
Example:
<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure>
<deployment>
<dependencies>
<system>
<paths>
<path name="com/sun/management"/>
</paths>
</system>
</dependencies>
</deployment>
</jboss-deployment-structure>A simple helper class with a main() method that produces a memory leak is located ih Tester.java
Run the Tester with different JVM-parameters (e.g.: -Xmx500m -XX:+UseG1GC) to experience detection.
- check/update dependency version in README.md
Bump version numbers, build with all checks enabled and - if successful - push everything:
mvn -U jgitflow:release-start jgitflow:release-finish
... and then wait for Travis-CI.