public class MemoryUsageTracker
extends java.lang.Object
In one tracker, WeakReference
s are used internally, so that shortly after a track(Object, long)
ed object is GC'd,
the getBytesUsed()
value decrements appropriately.
In another we let clients listen for SoftReference
expiration again using weak references.
Both only work with clients who opt-in with calls to these methods/instances.
This also includes a technique for clearing soft references.
If you have access to a console you can force it with:
org.apache.brooklyn.util.javalang.MemoryUsageTracker.forceClearSoftReferences()
Modifier and Type | Class and Description |
---|---|
static class |
MemoryUsageTracker.SoftUsageTracker
Tracking for soft usage through SoftlyPresent instances
|
Modifier and Type | Field and Description |
---|---|
static MemoryUsageTracker |
SOFT_REFERENCES
Shared instance for use for tracking memory used by
SoftReference . |
Constructor and Description |
---|
MemoryUsageTracker() |
Modifier and Type | Method and Description |
---|---|
static java.lang.String |
forceClearSoftReferences()
forces all soft references to be cleared by trying to allocate an enormous chunk of memory,
returns a description of what was done
(tune with
forceClearSoftReferences(long, int)
for greater than 200M precision in the output message, if you really care about that) |
static java.lang.String |
forceClearSoftReferences(long headroom,
int maxChunk)
as
forceClearSoftReferences() but gives control over headroom and max chunk size. |
long |
getBytesUsed() |
void |
track(java.lang.Object instance,
long bytesUsedByInstance) |
public static final MemoryUsageTracker SOFT_REFERENCES
SoftReference
.
Callers should only use this field to track(Object, long)
objects which have (or will soon have)
given up their strong references, so that only soft or weak references remain.
Provided size estimates are accurate, getBytesUsed()
will report
the amount of used memory which is reclaimable by collecting soft references.
This is particularly handy for tracking SoftReference
s, because otherwise you can quickly get to a state
where Runtime.freeMemory()
looks very low.
Also consider forceClearSoftReferences()
to get useful information.
public void track(java.lang.Object instance, long bytesUsedByInstance)
public long getBytesUsed()
public static java.lang.String forceClearSoftReferences()
forceClearSoftReferences(long, int)
for greater than 200M precision in the output message, if you really care about that)public static java.lang.String forceClearSoftReferences(long headroom, int maxChunk)
forceClearSoftReferences()
but gives control over headroom and max chunk size.
it tries to undershoot by headroom as it approaches maximum (and then overshoot)
to minimize the chance we take exactly all the memory and starve another thread;
and it uses the given max chunk size in cases where the caller wants more precision
(the available memory will be fragmented so the smaller the chunks the more it can
fill in, but at the expense of time and actual memory provisioned)