Java Memory APIs & Diagnostics

If you register a listener and never remove it, the event source keeps your object alive. A ThreadLocal value stays alive as long as the thread does — and pool threads live forever, so the value never goes away. Always deregister listeners and always call ThreadLocal.remove() in pooled code.

It means the garbage collector is working almost constantly (about 98% of the time) but barely freeing anything (less than 2% of the heap). The JVM gives up early instead of thrashing. It's an early-warning version of a heap problem: the heap is nearly full and the program is spending all its time collecting instead of doing real work.

Metaspace is the area that stores class metadata (the definitions of loaded classes), separate from the object heap. This OOME means too many classes are loaded — often because classes keep being created (dynamic proxies, code generation) or because old classes can't be unloaded (a classloader leak). Heap-space OOME is about objects; Metaspace is about class definitions.

Cleaner (Java 9+) is the modern, safe way to run cleanup when an object becomes unreachable. You register an object plus a cleanup action; Cleaner runs it later on a background thread. It replaced finalize() because finalizers were unpredictable, slow, and could resurrect objects or fail silently.

A ReferenceQueue is a queue the garbage collector puts reference objects onto after it clears their referent. You register a reference with a queue; later you poll or block on that queue to find out the object was collected, then react (usually cleanup).

A soft-reference cache has no size limit and no real eviction rules of its own — it just hopes the garbage collector will clear things at the right time. Under memory pressure it can dump everything at once and slow the app down. A real cache library lets you set size and time limits, so it behaves predictably.

-Xss sets each thread's stack size. A bigger value allows deeper recursion before a StackOverflowError. It only helps when recursion is legitimately deep but finite — it cannot fix recursion that never ends.

Even with a GC, you leak when objects stay strongly reachable but are never used again. Things like an ever-growing static list, listeners never removed, or ThreadLocals not cleared keep strong references alive, so the GC can't reclaim them.

WeakHashMap is a map that holds its keys with weak references. When a key is no longer used anywhere else, the garbage collector reclaims it and the map automatically removes that entry, so the map can't keep old keys alive.

Make object ownership and lifetime explicit. Never use unbounded caches — always bound size or add expiry. Pair every register/open/subscribe with an unregister/close/unsubscribe, ideally with try-with-resources. Clear ThreadLocals in pooled code. And watch live heap in production so slow leaks are caught early.

The JVM keeps an object alive if it can be reached from a starting point it trusts (a GC root) by following references. The strong reference is the Java keyword-free, ordinary handle you write; reachability from roots is the runtime rule the JVM applies to decide what survives.

A ReferenceQueue is a notification channel. You register a weak reference with a queue when you create it, and after the garbage collector clears that reference, it places the reference object on the queue. Polling the queue tells you which referents have been collected.

Give each plugin/app its own classloader, never let long-lived infrastructure hold strong references to plugin objects (use weak references and explicit deregistration), and clean up threads, ThreadLocals, drivers, and listeners on undeploy. Test by redeploying many times and confirming the old classloader is collected.

Rely on always-on low-overhead tools like Java Flight Recorder and GC logs for continuous insight, and reserve full heap dumps for when you really need object-level detail. When you must dump, do it on one instance taken out of rotation, write to fast local disk, and have a plan for where dumps go and how sensitive data in them is protected.

Make the class AutoCloseable so callers free the buffer promptly with try-with-resources. Also register it with a Cleaner as a safety net if they forget. Put the buffer handle in a separate state object the cleanup doesn't tie back to the wrapper, and make close() and the Cleaner path idempotent.

HotSpot keeps a soft-referenced object based on how much free memory there is and how long ago it was last used: more free memory means it lives longer. A JVM flag controls that ratio. Because it depends on free heap, the same code keeps soft references for different amounts of time depending on heap size and the garbage collector you run.

Standard Java/HotSpot does not do tail-call optimization, so even tail-recursive methods keep pushing stack frames and can overflow. To make deep recursion safe, rewrite it as a loop, often with your own explicit stack on the heap.

Weak references are good when you must associate data with objects you don't own and want that data to disappear automatically when those objects are no longer used. They go wrong when something still strongly holds the object, when you assume entries vanish on a schedule, or when an explicit bounded structure would be simpler.