Advanced Java

The JVM splits memory into the heap (objects, shared), per-thread stacks, Metaspace (class metadata, native memory), the code cache (JIT output) and other native areas (direct buffers, thread structures, GC data).

• Heap: young generation (Eden + two survivors) and old generation in generational collectors.
• Each thread has a stack of frames holding locals, operand stack and return info; -Xss sets its size.
• Metaspace replaced PermGen in Java 8 and lives in native memory.

Local primitives and object references live in stack frames; all objects and arrays are allocated on the heap (conceptually). A frame is discarded when the method returns.

• Objects can be shared across threads; stack data is thread-confined.
• Escape analysis may scalar-replace an object so it never exists on the heap.

The JMM defines when a write by one thread is guaranteed visible to a read by another through the happens-before relation. Without happens-before, the compiler and CPU may reorder or cache writes.

• Edges: unlock -> later lock of the same monitor; volatile write -> later read of that variable; Thread.start(); Thread.join(); final-field freeze at constructor end.
• Program order within one thread also forms happens-before.

volatile guarantees visibility and prevents reordering around the access (acquire/release semantics plus sequential consistency among volatiles). It does not make compound operations atomic.

volatile int counter;
void inc() { counter++; } // read, add, write: lost updates possible

• Use AtomicInteger, LongAdder or locks for read-modify-write.
• Good for flags and safe publication of immutable objects.

An object is safely published if its reference is handed over through a happens-before edge (volatile, lock, static initializer, concurrent collection). Properly constructed objects with final fields are visible fully initialized to any thread, even via a data race.

• The this reference must not escape from the constructor.
• Non-final fields of an unsafely published object may appear with default values.

Most objects die young (weak generational hypothesis), so the heap is split into a young generation collected often and cheaply by copying survivors, and an old generation collected rarely.

• New objects go to Eden; a minor GC copies live objects to a survivor space, ageing them.
• After surviving MaxTenuringThreshold cycles (or if survivors overflow) objects are promoted to old.
• Card tables / remembered sets track old-to-young references so a young GC need not scan old.

The GC marks everything reachable from GC roots: live thread stacks and registers, static fields of loaded classes, JNI references, and monitors held. Unreached objects are garbage, regardless of cycles.

• Java does not use reference counting, so cyclic structures are collected.
• Class loaders and their classes are roots-reachable only through live references.

Serial and Parallel are STW, throughput-oriented; G1 is the balanced region-based default; ZGC and Shenandoah are concurrent low-pause collectors.

• Serial: single thread, tiny heaps and containers.
• Parallel: multi-threaded STW, best raw throughput, pauses grow with heap.
• G1: regions, mixed collections, pause target via -XX:MaxGCPauseMillis (default 200ms).
• ZGC: colored pointers + load barriers, sub-millisecond pauses, regions, generational mode default in Java 23+.
• Shenandoah: Brooks pointer / load-reference barrier, concurrent compaction, pauses independent of heap size.

G1 divides the heap into equal regions (1-32MB) that are dynamically Eden, Survivor, Old or Humongous. It collects a "collection set" chosen to meet the pause target, preferring regions with most garbage.

• Young GC: STW evacuation of Eden/Survivor regions.
• Concurrent marking starts when occupancy hits InitiatingHeapOccupancyPercent (45%; adaptive since Java 9).
• Mixed GCs then evacuate young plus the most garbage-rich old regions.
• Full GC (parallel since Java 10) is the fallback.

An object of size >= region/2 is humongous: it takes whole contiguous regions directly in old space, bypassing Eden. They can cause fragmentation, premature concurrent cycles and Full GCs.

• Reclaimed at young GC if proven dead (eager reclaim) for primitive arrays without references.
• Mitigations: raise -XX:G1HeapRegionSize, chunk large buffers, reuse arrays, avoid giant byte[] copies.
• Diagnose with -Xlog:gc+humongous=debug.

ZGC does marking, relocation and reference processing concurrently with application threads. Load barriers check pointer metadata ("colors") and fix up stale references on access, so STW phases only scan roots.

• Pauses are typically well under 1ms and do not scale with heap or live set.
• Supports multi-terabyte heaps; generational ZGC (-XX:+ZGenerational, Java 21; the only mode from Java 24) improves throughput.
• Costs: load barrier overhead, more CPU and memory headroom required.

Both are concurrent-compacting, but Shenandoah uses a load-reference barrier (since Java 13, formerly Brooks forwarding pointer) with reference-forwarding in the object, while ZGC uses colored pointers and load barriers on 64-bit only.

• Shenandoah ships in OpenJDK builds from many vendors (not Oracle JDK); ZGC is in all.
• Shenandoah works on 32-bit and compressed oops; ZGC historically did not support compressed oops (it does not use them).
• Enable with -XX:+UseShenandoahGC.

Parallel GC (-XX:+UseParallelGC) uses multiple threads for STW young and full collections to maximize application throughput, accepting longer pauses.

• Good for batch/ETL jobs where total runtime matters and pauses do not.
• Tunables: -XX:ParallelGCThreads, -XX:GCTimeRatio, -XX:MaxGCPauseMillis.
• Old gen is compacted by a full GC, whose pause grows with live set.

Start with heap sizing and the collector choice, then pause target; avoid micro-flags until logs justify them.

java -Xms4g -Xmx4g -XX:+UseG1GC -XX:MaxGCPauseMillis=150 \
  -XX:MaxRAMPercentage=75 -Xlog:gc*:file=gc.log:time,uptime \
  -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/dumps -jar app.jar

• -Xms = -Xmx avoids resize pauses.
• -XX:NewRatio/-Xmn size young; G1 sizes it adaptively, so fixing it disables adaptation.
• -XX:+AlwaysPreTouch pre-commits pages for predictable latency.

Since Java 9 unified logging replaces -XX:+PrintGCDetails: -Xlog:gc* writes tagged, levelled output. Key signals are pause duration, cause, heap before/after, and frequency.

• Pause Young (Normal) (G1 Evacuation Pause) 512M->120M(1024M) 8.3ms.
• Causes: G1 Humongous Allocation, Metadata GC Threshold, System.gc(), Allocation Failure.
• Tools: GCViewer, GCeasy, JDK Mission Control.

jcmd is the modern unified tool; the others are specialized.

• jstack <pid>: thread dump with locks and deadlock detection.
• jmap -dump:live,format=b,file=h.hprof <pid>: heap dump; -histo for class histogram.
• jstat -gcutil <pid> 1000: live GC statistics.
• jcmd <pid> Thread.print | GC.heap_dump | GC.class_histogram | VM.flags | JFR.start.

JFR is a low-overhead (typically 1-2%) event recorder built into the JVM, free since Java 11. It captures GC, allocation, locks, I/O, CPU samples and custom events into a .jfr file analyzed in JDK Mission Control or jfr CLI.

java -XX:StartFlightRecording=duration=60s,filename=rec.jfr,settings=profile -jar app.jar
jcmd <pid> JFR.start name=r1 settings=profile
jcmd <pid> JFR.dump name=r1 filename=/tmp/r1.jfr
jfr summary rec.jfr

• default profile is safe for always-on; profile has more detail.
• Allocation sampling attributes hot allocation sites without full instrumentation.

Loaders form a hierarchy: bootstrap (core modules, native), platform (formerly extension), application (classpath). loadClass first delegates to the parent and only loads itself if the parent fails.

• Guarantees core classes like java.lang.String cannot be replaced by user code.
• A class's identity is (name, defining loader); the same bytes in two loaders are different classes.
• Servlet containers and OSGi invert or break delegation for isolation.

Loading -> linking (verification, preparation, resolution) -> initialization. Initialization runs static initializers (<clinit>) exactly once, lazily, under a lock, on first active use.

• Triggers: new, static method/non-constant field access, reflection Class.forName(name), subclass init.
• Constants (static final compile-time) do not trigger init.
• Circular initialization between classes can see default values or deadlock across threads.

PermGen was a fixed-size heap region for class metadata (removed in Java 8). Metaspace stores that metadata in native memory and grows on demand, bounded by -XX:MaxMetaspaceSize (unlimited by default).

• Metaspace is freed when the owning class loader is garbage collected.
• -XX:MetaspaceSize is the high-water mark that triggers the first GC, not a reservation.

HotSpot interprets bytecode first, profiles it, then compiles hot methods: C1 (fast, light optimization) at tiers 1-3 and C2 (aggressive) at tier 4. Tiered compilation is on by default.

• Tier 0 interpreter; tier 3 is C1 with full profiling; tier 4 is C2.
• Thresholds are invocation plus back-edge (loop) counters; OSR compiles hot loops mid-execution.
• Deoptimization reverts to the interpreter when speculative assumptions break (class loaded, type profile changes).

Inlining is the foundational optimization enabling the rest: escape analysis, constant folding, dead code elimination, loop unrolling, range-check elimination, devirtualization and lock coarsening/elision.

• Monomorphic and bimorphic call sites are inlined with a type guard; megamorphic sites use vtable/itable dispatch.
• Methods under MaxInlineSize (35 bytecodes) or hot ones up to FreqInlineSize (325) are inlinable.
• Inspect with -XX:+PrintCompilation, -XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining.

C2 analyzes whether an object can be observed outside its method or thread. If not, it can scalar-replace it (fields become locals, no allocation) and elide its locks.

double dist(double x, double y) {
    Point p = new Point(x, y);   // may never be allocated
    return Math.sqrt(p.x * p.x + p.y * p.y);
}

• Fails when the object is stored in a field, passed to a non-inlined call, or returned.
• Flag: -XX:+DoEscapeAnalysis (default on).
• Not "stack allocation": HotSpot has no real stack allocation.

Strong references block collection. Soft are cleared under memory pressure, weak at the next GC when no strong refs remain, and phantom are enqueued after the object is finalized and used for cleanup actions (get() always returns null).

• Soft: memory-sensitive caches (policy via -XX:SoftRefLRUPolicyMSPerMB).
• Weak: canonicalizing maps like WeakHashMap, listener registries.
• Phantom + ReferenceQueue: resource cleanup; java.lang.ref.Cleaner wraps this.

Try-with-resources gives deterministic closing. Cleaner (Java 9+) is a safety net run by a daemon thread when an object becomes phantom reachable. finalize() is deprecated for removal because it is slow, unpredictable and can resurrect objects.

• The cleaning action must not reference the object it cleans, or it will never run.
• Never rely on either for releasing scarce resources promptly.

Generic type parameters are checked at compile time and erased to their bounds (or Object) in bytecode, with casts inserted. At runtime List<String> and List<Integer> are both List.

• Cannot do new T(), new T[n], instanceof List<String>, or overload by type argument.
• Generic info persists in signatures and can be read through reflection (getGenericSuperclass).
• Bridge methods preserve polymorphism after erasure.

Producer Extends, Consumer Super: use ? extends T when you only read T from a structure and ? super T when you only write T into it. List<? extends Number> is covariant and read-only (except null); List<? super Integer> is contravariant and write-friendly.

static <T> void copy(List<? super T> dst, List<? extends T> src) {
    for (T t : src) dst.add(t);
}

• Collections.copy and Comparator<? super T> follow PECS.
• ? alone means unknown type, usable for read as Object.

Heap pollution occurs when a variable of a parameterized type refers to an object that is not of that type, which surfaces later as a ClassCastException at an unrelated line. Generic varargs create an array of the erased type, which enables it.

static <T> T[] toArray(T... xs) { return xs; } // unchecked warning
String[] s = toArray("a", 1);                   // CCE at call site

• @SafeVarargs asserts the method does not expose the array (allowed on static, final, private methods).
• Raw types and unchecked casts are the other sources.

When a subclass overrides a generic method with a concrete type, the compiler generates a synthetic bridge method with the erased signature that casts and delegates, preserving polymorphism.

class Box<T> { void set(T t) {} }
class IntBox extends Box<Integer> {
    @Override void set(Integer i) {} // plus bridge: set(Object)
}

• Also used for covariant return types.
• Visible via javap -p or Method.isBridge().

<T extends Comparable<T>> constrains T to types comparable with themselves. Multiple bounds use &: <T extends Number & Comparable<T>>, with the class first.

static <T extends Comparable<? super T>> T max(Collection<? extends T> c) {
    Iterator<? extends T> it = c.iterator();
    T best = it.next();
    while (it.hasNext()) { T x = it.next(); if (x.compareTo(best) > 0) best = x; }
    return best;
}

• ? super T in Comparable lets a java.sql.Timestamp use its parent's compareTo.
• Erasure of the type variable is its first bound.

Java 9's module system adds module-info.java declaring a module's name, dependencies (requires) and exported packages. It provides strong encapsulation and reliable configuration at startup.

module com.acme.orders {
    requires java.sql;
    requires transitive com.acme.common;
    exports com.acme.orders.api;
    opens com.acme.orders.model to com.fasterxml.jackson.databind;
    uses com.acme.spi.Tax;
    provides com.acme.spi.Tax with com.acme.orders.VatTax;
}

• Non-exported packages are inaccessible even via public and reflection.
• jlink builds trimmed runtime images.

A plain JAR on the module path becomes an automatic module (name from Automatic-Module-Name or filename) that exports and opens everything and reads all modules. The classpath contents form the unnamed module.

• Since Java 16/17, JDK internals are strongly encapsulated: --illegal-access is gone.
• Workarounds for legacy libraries: --add-opens java.base/java.lang=ALL-UNNAMED, --add-exports.
• Split packages across modules are forbidden on the module path.

JNI lets Java call C/C++ through native methods bound to functions in a shared library loaded with System.loadLibrary. Headers are generated by javac -h.

• Drawbacks: boilerplate, crashes the whole JVM on bugs, manual local/global reference management, slow-ish transitions, hard to test and port.
• Critical sections pin arrays or hamper GC (GetPrimitiveArrayCritical).
• Used by many JDK internals and libraries (zstd, RocksDB).

The FFM API (java.lang.foreign, final in Java 22) replaces JNI and Unsafe for native interop: Linker binds C functions, MemorySegment gives bounds-checked off-heap access, and Arena controls lifetime deterministically.

Linker linker = Linker.nativeLinker();
MethodHandle strlen = linker.downcallHandle(
    linker.defaultLookup().find("strlen").orElseThrow(),
    FunctionDescriptor.of(ValueLayout.JAVA_LONG, ValueLayout.ADDRESS));
try (Arena a = Arena.ofConfined()) {
    long n = (long) strlen.invokeExact(a.allocateFrom("hello")); // 5 (Java 22+)
}

• Pure Java, no C glue; jextract generates bindings from headers.
• Safe: spatial and temporal checks prevent use-after-free.

ByteBuffer.allocateDirect allocates memory outside the heap, avoiding a copy during native I/O. Allocation is expensive and freed only when the small Buffer object is garbage collected.

• Limited by -XX:MaxDirectMemorySize (defaults to roughly -Xmx).
• Good for long-lived, reused buffers (Netty pools them).
• Leaks appear as native memory growth with a small heap; error: OutOfMemoryError: Direct buffer memory.

Two threads write independent variables that sit on the same 64-byte cache line, so the line ping-pongs between cores via the coherence protocol and throughput collapses.

• Symptom: scaling worse than linear with threads while no lock contention exists.
• Fixes: padding, @jdk.internal.vm.annotation.Contended (needs -XX:-RestrictContended), splitting per-thread state, LongAdder (uses @Contended cells).
• Verify with perf c2c or JMH multi-threaded benchmarks.

Autoboxing wraps primitives into objects (Integer), costing allocation, an extra pointer indirection and GC pressure. List<Integer> uses about 16 bytes per element plus the 4-8 byte reference versus 4 for int[].

• Integer.valueOf caches -128..127 (extendable via -XX:AutoBoxCacheMax).
• Prefer primitive streams (IntStream), primitive-specialized collections (Eclipse Collections, fastutil), long accumulators.
• Escape analysis can remove some boxing, not reliably.

Each thread gets a Thread-Local Allocation Buffer, a chunk of Eden, so most allocations are a pointer bump with no locking. When the TLAB is full, a new one is requested; huge objects bypass it.

• Allocation is typically ~10-20 instructions in compiled code.
• Tuning: -XX:+PrintTLAB, -XX:TLABSize, -XX:-ResizeTLAB rarely needed.
• Allocation rate (MB/s) drives young GC frequency.

With heaps under ~32GB, HotSpot stores references as 32-bit values scaled by object alignment (8 bytes), halving reference size. Beyond about 32GB the JVM switches to 64-bit references and memory use jumps.

• -XX:+UseCompressedOops is automatic; check with -XX:+PrintFlagsFinal.
• A 40GB heap may hold less data than a 31GB one.
• Class pointers are compressed separately (UseCompressedClassPointers).

sun.misc.Unsafe offers unchecked memory and CAS operations used by JDK and frameworks; it is being phased out. VarHandle (Java 9) is the supported replacement for fields, arrays and buffers with defined memory-ordering modes.

class Counter {
    volatile int n;
    static final VarHandle N;
    static { try { N = MethodHandles.lookup().findVarHandle(Counter.class, "n", int.class); }
             catch (ReflectiveOperationException e) { throw new ExceptionInInitializerError(e); } }
    int incr() { return (int) N.getAndAdd(this, 1) + 1; }
}

• Modes: plain, opaque, acquire/release, volatile; compareAndSet, getAndAdd.
• JEP 471 deprecates memory-access methods of Unsafe for removal.

From weakest to strongest: plain (no guarantees), opaque (coherence, no tearing, eventually visible), release/acquire (writes before a release are visible after the matching acquire), volatile (total order across all volatile accesses).

• Release/acquire suffices for producer/consumer handoff and is cheaper on ARM.
• x86 gives acquire/release nearly for free; volatile writes still need a fence.
• Used inside AtomicXxx.lazySet (release) and JCTools queues.

Since Java 10 (backported to 8u191) the JVM reads cgroup limits to size the default heap and CPU count. Default max heap is 25% of container memory; -XX:MaxRAMPercentage adjusts it.

• availableProcessors() derives from CPU quota; this sizes GC threads, ForkJoin common pool and compiler threads.
• -XX:ActiveProcessorCount=N overrides.
• -XX:+UseContainerSupport is on by default.

Container limit = heap + Metaspace + code cache + thread stacks + direct memory + GC overhead + native libraries. A rough rule is heap at 60-75% of the limit.

FROM eclipse-temurin:21-jre
ENV JAVA_TOOL_OPTIONS="-XX:MaxRAMPercentage=70 -XX:+ExitOnOutOfMemoryError"
COPY app.jar /app.jar
ENTRYPOINT ["java", "-jar", "/app.jar"]

• Verify real footprint with -XX:NativeMemoryTracking=summary and jcmd VM.native_memory.
• The kernel OOM killer sends SIGKILL (exit 137) when the cgroup limit is exceeded, with no Java stack trace.

NMT is a JVM feature tracking its own native allocations by category (heap, class, thread, code, GC, internal, symbol). Enable with -XX:NativeMemoryTracking=summary|detail, query with jcmd <pid> VM.native_memory summary.

• Use baseline and summary.diff to find growth.
• Overhead is 5-10% for detail, small for summary.
• It does not see allocations by third-party native libraries or glibc fragmentation.

A safepoint is a state in which all Java threads are paused at known points so the VM can perform operations such as GC, deoptimization, biased lock revocation (removed) or thread dumps. Threads poll at loop back-edges and method returns.

• "Time to safepoint" can be long if one thread is in a long counted loop without polls (reduced by loop strip mining).
• Diagnose with -Xlog:safepoint.
• Pauses reported as application-stopped time can exceed GC time.

Warm-up, JIT, dead-code elimination, constant folding, loop optimizations and GC make hand-rolled timing loops lie. JMH runs forked JVMs, warm-ups, multiple iterations and provides Blackhole to defeat dead-code elimination.

@State(Scope.Thread)
@BenchmarkMode(Mode.AverageTime) @OutputTimeUnit(TimeUnit.NANOSECONDS)
@Warmup(iterations = 5) @Measurement(iterations = 5) @Fork(2)
public class ParseBench {
    String s = "12345";
    @Benchmark public int parse() { return Integer.parseInt(s); }
}

• Return results or sink to Blackhole; keep inputs in non-final @State fields.
• Use -prof gc and -prof perfasm for allocation and assembly.

Pitfalls: final or literal inputs get constant-folded; shared mutable Scope.Benchmark state gives false sharing; benchmark loops written by hand defeat JMH's harness; trivial benchmarks measure the harness.

• Never write loops inside @Benchmark expecting JMH to scale; JMH may unroll them incorrectly.
• @Setup(Level.Invocation) adds overhead comparable to the work measured.
• Check error bars; compare distributions, not single numbers; pin CPU frequency.

A Java leak is an object that is reachable but no longer needed. The usual causes are unbounded collections, static fields, listeners never deregistered, ThreadLocal in pooled threads, unclosed resources and class loader leaks.

• Caches without eviction or size bound.
• Inner classes holding this; lambdas capturing large objects.
• ThreadLocal values staying alive for as long as pool threads live.
• String.substring-style retention was fixed in Java 7u6.

Each thread holds a ThreadLocalMap with weak keys and strong values. In a pooled thread that never dies, a value is retained until the thread removes it, and if the value references its class loader, the whole application is retained after redeploy.

private static final ThreadLocal<Buffer> BUF = ThreadLocal.withInitial(Buffer::new);
try { use(BUF.get()); } finally { BUF.remove(); }

• Always remove() in finally for request-scoped data.
• Prefer scoped values (preview/final in recent JDKs) or explicit passing with virtual threads.

WeakHashMap holds keys weakly, so an entry disappears when the key is no longer strongly referenced elsewhere; useful for metadata attached to objects. IdentityHashMap compares keys with == and System.identityHashCode, used for graph traversal and serialization.

• WeakHashMap is not thread-safe; wrap with Collections.synchronizedMap.
• Interned String literals or boxed small values as keys never expire.

CDS maps a pre-parsed archive of JDK (and with AppCDS, application) classes into memory, cutting startup and sharing memory across JVMs. GraalVM Native Image compiles to a native binary ahead of time: instant startup and low memory, but no JIT peak performance, closed-world assumptions and reflection configuration.

• Dynamic archive: -XX:ArchiveClassesAtExit=app.jsa then -XX:SharedArchiveFile=app.jsa.
• Native image needs metadata for reflection, proxies and resources (Spring Boot 3 generates hints).
• Project Leyden is working toward AOT caches for the standard JVM.

Virtual threads are heap-allocated continuations mounted on carrier threads; their stacks are stored as stack chunk objects on the heap and grow on demand, so millions are feasible.

• Pinning (blocking in synchronized before Java 24, or native frames) stalls the carrier; diagnose with -Djdk.tracePinnedThreads=full or the JFR jdk.VirtualThreadPinned event.
• jstack does not list them; use jcmd <pid> Thread.dump_to_file -format=json file.
• They are not GC roots until mounted/referenced; abandoned blocked ones can leak.

Capture a heap dump at failure, then find the dominator tree to see what retains the memory. Distinguish a leak (steady growth after full GCs) from undersizing (stable but too small).

java -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/dumps -jar app.jar
jcmd <pid> GC.class_histogram | head -20
jcmd <pid> GC.heap_dump /dumps/live.hprof

• Open in Eclipse MAT: leak suspects report, dominator tree, path to GC roots.
• Compare two histograms taken minutes apart to see which class count grows.
• Check GC log: if post-GC occupancy keeps rising, it is a leak.

The Parallel collector spent more than 98% of time in GC while recovering less than 2% of the heap, over several consecutive collections. It is a heuristic that fails fast instead of crawling.

• The root cause is the same as heap exhaustion: leak or undersizing.
• -XX:-UseGCOverheadLimit disables the check (usually worsens things).
• G1 and ZGC do not produce this message; they throw plain heap-space OOM or stall.

Each redeploy creates a new web-app class loader. If anything outside it keeps a reference to a class or object from the old loader (a ThreadLocal, a JDBC driver registered in DriverManager, a thread, a shutdown hook), the old loader and all its classes stay in Metaspace.

• Heap dump: find multiple instances of WebappClassLoader and trace the GC root path.
• Use jcmd <pid> VM.classloader_stats and GC.class_stats.
• Fix: deregister drivers, stop threads, clear ThreadLocals in contextDestroyed; do not hot-redeploy in production.

The OS refused a new thread: per-process or per-user limit (ulimit -u, pid_max, cgroup pids.max) or no native memory left for the thread's stack (default 1MB virtual each).

• Check thread count with jcmd <pid> Thread.print | grep -c '^"', find the leaking pool.
• Reduce -Xss, bound pools, replace thread-per-task with virtual threads or a bounded executor.
• A larger heap leaves less address space or memory for stacks in a fixed container.

Direct buffers are capped by -XX:MaxDirectMemorySize, and their native memory is freed only after their small heap handle objects are collected. With low heap pressure, GC rarely runs, so native memory fills first.

• Typical in Netty/NIO apps allocating per request without pooling or release (ReferenceCountUtil.release).
• Calling System.gc() is the JDK's last-resort retry (disabled by -XX:+DisableExplicitGC).
• Track with jcmd VM.native_memory, JFR, and Netty's leak detector (-Dio.netty.leakDetection.level=paranoid).

The kernel OOM killer ended the process because RSS exceeded the cgroup limit. The heap (-Xmx) was within its limit, but total footprint was not: Metaspace, thread stacks, direct buffers, code cache, GC structures and malloc fragmentation add up.

• Lower -Xmx or MaxRAMPercentage to leave 25-40% headroom.
• Use NMT to see JVM-internal usage; set MALLOC_ARENA_MAX=2 for glibc fragmentation.
• Kubernetes shows OOMKilled in kubectl describe pod.

Correlate spikes with GC logs first: evacuation pauses, mixed GCs, Full GCs, humongous allocations, or non-GC safepoints. Tune only the observed cause.

• Long young pauses: reduce survivor copying, lower allocation rate, check large ParallelGCThreads mismatch with CPU quota.
• Long mixed pauses: raise -XX:G1MixedGCCountTarget, lower -XX:G1HeapWastePercent tuning.
• Full GCs: lower InitiatingHeapOccupancyPercent, add headroom (-XX:G1ReservePercent), find humongous objects.
• If targets are < 10ms, move to ZGC/Shenandoah.

Decide by SLOs. Default to G1. Choose ZGC (or Shenandoah) when tail latency matters on large heaps and you can spare 10-20% more CPU and memory. Choose Parallel for batch where throughput dominates. Use Serial for tiny containers.

• Measure with realistic load; compare p99 latency, throughput, RSS.
• ZGC suits heaps from a few GB to TBs; below ~1GB the barrier cost rarely pays.
• Containers with < 2 CPUs get Serial by default, so force the collector explicitly.

Bound the cache by size or time. Use Caffeine (maximumSize, expireAfterWrite) instead of a raw HashMap; use LinkedHashMap with removeEldestEntry for a simple LRU; avoid SoftReference as the sole policy.

Map<String, Data> lru = new LinkedHashMap<>(16, 0.75f, true) {
    protected boolean removeEldestEntry(Map.Entry<String, Data> e) { return size() > 1000; }
};

• Make sure the key's equals/hashCode are stable and cheap.
• That LinkedHashMap is not thread-safe; wrap or use Caffeine.

Arrays and strings are symptoms. In MAT, use the dominator tree and "merge shortest paths to GC roots" on the largest byte[] to find which owner retains them: a cache, a request log buffer, a session store, or a result-set holder.

• Since Java 9, String is backed by byte[] (compact strings), hence byte[] dominates.
• Duplicates: check jcmd GC.heap_dump plus MAT "duplicate classes"/string duplicates; -XX:+UseStringDeduplication helps with G1.
• Look at JFR "Old Object Sample" event for leak candidates with allocation stacks.

Take a thread dump with jstack -l <pid> or jcmd <pid> Thread.print; the JVM reports "Found one Java-level deadlock" with the cycle of monitors and owners. Take multiple dumps spaced seconds apart to confirm threads are stuck, not progressing.

"worker-1" waiting to lock monitor 0x...(object A), which is held by "worker-2"
"worker-2" waiting to lock monitor 0x...(object B), which is held by "worker-1"

• Fix with a consistent lock ordering, tryLock with timeout, or by shrinking lock scope.
• ThreadMXBean.findDeadlockedThreads() detects it programmatically (including java.util.concurrent locks).

Map the busiest OS thread to a Java thread: find the thread ID with top -H -p <pid>, convert to hex, and look up nid=0x... in a jstack dump. Then confirm with JFR or async-profiler.

top -H -p 1234            # note TID 1260
printf '%x\n' 1260        # 4ec
jstack 1234 | grep -A 15 'nid=0x4ec'

• If the hot thread is "GC Thread" or "C2 CompilerThread", it is GC or JIT activity, not business code.
• Take several dumps; one sample can mislead.

The JVM is interpreting and compiling; classes load lazily; caches and connection pools are cold. Mitigate with warm-up traffic or synthetic requests before readiness, CDS/AppCDS, and gradual traffic ramp.

• Readiness probes should wait until warm-up completes.
• Options: Class Data Sharing archives, CRaC checkpoints, GraalVM native image for short-lived services.
• Increase compiler threads (-XX:CICompilerCount) if CPU quota is tiny and compilation starves.

After warm-up, C2 inlines sum, sees Pair does not escape, and scalar-replaces it: zero allocation per call. When the pair is stored into a field, it escapes and allocates.

record Pair(int a, int b) {}
static int sum(int x, int y) { Pair p = new Pair(x, y); return p.a() + p.b(); }

• Verify with JMH -prof gc (gc.alloc.rate.norm near 0 B/op) or by comparing with -XX:-DoEscapeAnalysis.
• Output: sum(2, 3) returns 5 regardless; only performance differs.

Typically true then null after System.gc(), because the only strong reference was dropped. The output is not guaranteed since System.gc() is a hint, though HotSpot honors it by default.

Object o = new Object();
WeakReference<Object> w = new WeakReference<>(o);
System.out.println(w.get() != null); // true
o = null;
System.gc();
System.out.println(w.get());         // usually null

• With -XX:+DisableExplicitGC or in a JIT-optimized loop it may still be alive.
• Never base program logic on this behaviour.

SoftReference fits "free when memory is tight", but the policy is JVM-controlled (LRU by time since last access scaled by free heap: SoftRefLRUPolicyMSPerMB, default 1000ms per free MB). It can cause GC thrashing and unpredictable hit rates.

• Better: bounded Caffeine cache with weight-based eviction (maximumWeight) and optional softValues().
• Soft refs add GC reference-processing cost and survive many young GCs, bloating old gen.
• ZGC and G1 clear soft refs before throwing OOM.

It compiles but throws ArrayStoreException at runtime, since arrays are covariant and reified while generics are invariant.

Object[] arr = new String[1];
arr[0] = 1;                          // ArrayStoreException
List<Object> list = new ArrayList<String>(); // compile error

• Arrays check the element type on every store; generics are checked only at compile time.
• Mixing arrays and generics is the source of "generic array creation" errors.

After erasure both methods have the signature m(List), a "name clash: same erasure". Overloading cannot distinguish them.

• Workarounds: rename the methods, add a distinguishing parameter, or use a wrapper type.
• The same erasure rule makes instanceof List<String> illegal.

The library reflectively accesses non-open JDK internals, blocked by strong encapsulation since Java 16/17. Upgrade to a version that supports modern Java; as a stop-gap add --add-opens.

java --add-opens java.base/java.lang=ALL-UNNAMED \
     --add-opens java.base/java.util=ALL-UNNAMED -jar app.jar

• Find offenders with jdeps --jdk-internals app.jar.
• Put the flags in JAVA_TOOL_OPTIONS or the manifest Add-Opens attribute.

On the classpath the first JAR in order wins; the other is silently shadowed. This produces NoSuchMethodError, NoClassDefFoundError or odd behaviour when versions differ ("JAR hell").

• Diagnose with -verbose:class, -Xlog:class+load, mvn dependency:tree, or Class.getProtectionDomain().getCodeSource().
• Fix with dependency convergence/dependencyManagement, shading with relocation, or module path (rejects split packages).

Extend ClassLoader, override findClass (not loadClass, to keep parent delegation), read bytes and call defineClass.

class DirLoader extends ClassLoader {
    private final Path root;
    DirLoader(Path root, ClassLoader parent) { super(parent); this.root = root; }
    @Override protected Class<?> findClass(String name) throws ClassNotFoundException {
        try {
            byte[] b = Files.readAllBytes(root.resolve(name.replace('.', '/') + ".class"));
            return defineClass(name, b, 0, b.length);
        } catch (IOException e) { throw new ClassNotFoundException(name, e); }
    }
}

• Risks: class loader leaks, duplicate class identities, LinkageError if defined twice, security.
• Unloading requires dropping all references to the loader, its classes and instances.

Output is A, B, ctor: the superclass static block runs first, then the subclass static block, only when the class is first used; the instance constructor runs after.

class P { static { System.out.print("A "); } }
class C extends P {
    static { System.out.print("B "); }
    C() { System.out.print("ctor "); }
}
new C(); // A B ctor

• A second new C() prints only ctor.
• C.CONSTANT for a compile-time constant would trigger none.

Primitive streams avoid boxing and unboxing, objects allocation and pointer chasing. The gap is plausible for tight loops but must be validated with JMH, including allocation rates, since a naive timer may reflect JIT warm-up.

• Use @Benchmark returning the result; inspect -prof gc for B/op.
• Real gains shrink when the source is already List<Integer> (unboxing remains).
• The boxed pipeline can be partially optimized by escape analysis for small cases.

Both fields are adjacent in memory within one cache line, so each write invalidates the other core's copy: false sharing. Pad or isolate them.

class Counters {
    @jdk.internal.vm.annotation.Contended volatile long a;
    @jdk.internal.vm.annotation.Contended volatile long b;
}

• @Contended outside the JDK needs -XX:-RestrictContended and --add-exports java.base/jdk.internal.vm.annotation=ALL-UNNAMED.
• Portable alternative: manual padding with unused long fields (JIT may remove or reorder them) or arrays with stride of 8-16 elements.
• Best: use LongAdder, or aggregate per-thread then merge.

Application threads are blocked waiting for memory because allocation outpaced concurrent reclamation. Give ZGC more headroom or concurrency, or cut allocation.

• Increase -Xmx (ZGC needs spare heap, often 20-30%) or -XX:SoftMaxHeapSize tuning.
• More GC threads: -XX:ConcGCThreads; ensure the container has enough CPU.
• Use generational ZGC (-XX:+ZGenerational on 21) to reclaim short-lived objects cheaply.
• Reduce allocation rate with JFR allocation profiling.

A Full GC means G1 could not reclaim space fast enough: evacuation failure, humongous fragmentation or marking started too late. Fix the cause.

• Start marking earlier: lower -XX:InitiatingHeapOccupancyPercent (or keep adaptive IHOP and add reserve -XX:G1ReservePercent).
• Add heap or reduce allocation rate and promotion (fewer long-lived temporary objects).
• Remove/size humongous objects; avoid System.gc() calls and RMI periodic GC (-XX:+DisableExplicitGC or -XX:+ExplicitGCInvokesConcurrent).
• Log: -Xlog:gc*,gc+phases=debug; look for "To-space exhausted".

The JVM derives availableProcessors() from the cgroup CPU limit (quota/period, rounded up). A limit of 500m yields 1 processor, so the common ForkJoin pool, GC threads and compiler threads shrink, and with under 2 CPUs the JVM picks Serial GC.

• Check: jcmd <pid> VM.info or print Runtime.getRuntime().availableProcessors().
• Fix: raise the CPU limit, force -XX:+UseG1GC and -XX:ActiveProcessorCount=N where justified.
• CPU limits also throttle (CFS) bursts, causing latency spikes even when average usage is low.

The JIT eliminated the work: either the result is unused (dead-code elimination) or the inputs are compile-time constants (constant folding). Fix by returning the value or passing it to a Blackhole, and reading inputs from non-final @State fields.

@State(Scope.Thread)
public class B {
    double x = 42.0;                       // not final: prevents folding
    @Benchmark public double sqrt() { return Math.sqrt(x); }
}

• Sub-nanosecond results per op are a red flag.
• Verify via -prof perfasm or -prof gc that the code is really executed.

Check forks (use at least 2-3), warm-up length, CPU frequency scaling/turbo, noisy neighbours, thermal throttling, GC activity, and profile pollution from polymorphic call sites.

• Use @Fork(3), sufficient @Warmup, and examine the score error (±) and per-fork results.
• Pin to cores (taskset), disable turbo/power saving, run on a quiet machine, avoid laptops on battery.
• Run -prof gc to correlate with allocation; try -XX:+UseParallelGC or -XX:+UseEpsilonGC to isolate GC noise.

Without volatile or synchronization, the JIT may hoist the field read out of the loop, so the reader never sees the writer's update and spins forever.

class Worker {
    boolean stop;                       // should be volatile
    void run() { while (!stop) { /* work */ } }
    void halt() { stop = true; }
}

• Make stop volatile, or use AtomicBoolean/interruption.
• It may appear to work in the interpreter or debug mode and fail after JIT compilation.

Without volatile, the write of the reference may become visible before the writes inside the constructor (reordering), so another thread sees a non-null reference to an incompletely initialized object.

class S {
    private static volatile S inst;           // volatile is required
    static S get() {
        S s = inst;
        if (s == null) { synchronized (S.class) { s = inst; if (s == null) inst = s = new S(); } }
        return s;
    }
}

• Simpler options: the initialization-on-demand holder idiom or an enum singleton.
• If all fields are final, the object is safe even without volatile.

Idle pool workers waiting on the queue are normal. The 50 BLOCKED threads contending for one synchronized monitor indicate a lock bottleneck, so find the single owner thread ("locked <0x...>") and what it is doing.

• Look at the owner's stack: usually slow I/O, a DB call, or heavy computation inside the critical section.
• Fix: shrink the critical section, move I/O outside, use finer-grained locks, ConcurrentHashMap, or read-write/stamped locks.
• JFR jdk.JavaMonitorEnter events show contention totals.

Slow steady growth after full GC confirms a leak. Use JFR's Old Object Sample (low overhead) in production or two GC.class_histogram snapshots hours apart, then take a heap dump for the growing class.

jcmd <pid> JFR.start settings=profile name=leak duration=1h path-to-gc-roots=true filename=leak.jfr
jcmd <pid> GC.class_histogram > h1.txt

• Examine the OldObjectSample events with root paths in JMC.
• In MAT compare dumps via "compare to baseline".
• Review recent changes for new caches, listeners, metrics tags with unbounded cardinality.

A long-lived publisher holds a strong reference to the listener, which holds its owner. Deregister in a lifecycle hook (close, @PreDestroy) or store listeners weakly.

class Bus {
    private final List<Consumer<String>> subs = new CopyOnWriteArrayList<>();
    Runnable subscribe(Consumer<String> c) { subs.add(c); return () -> subs.remove(c); }
}

• Return an unsubscribe handle so callers can clean up.
• Beware lambdas and inner classes capturing this.

Something creates a new class on every call: building a new Proxy, CGLIB Enhancer, Groovy/JS script, or MethodHandle/lambda spinner per request without caching, or a fresh class loader each time.

• Heap/class histogram: many classes with names like $$EnhancerByCGLIB$$ or $Proxy123.
• jcmd <pid> VM.classloader_stats; -Xlog:class+load shows the stream.
• Fix by caching generated classes/proxies and reusing factories.

:live triggers a full GC and the dump itself pauses all threads for the time it takes to write the heap, from seconds to minutes for big heaps, plus disk usage equal to the live set.

• Alternatives: jcmd GC.class_histogram for a cheap overview; JFR Old Object Sample; take the dump from one instance after removing it from the load balancer.
• Ensure free disk, compress the dump (gzip), and protect it as it contains secrets.
• -XX:+HeapDumpOnOutOfMemoryError captures the state at failure.

Heap max of 75% leaves too little for off-heap use (Metaspace ~150MB, code cache up to 240MB, stacks, direct buffers, G1 remembered sets ~10%). Reduce the heap and measure the footprint.

java -XX:MaxRAMPercentage=60 -XX:MaxDirectMemorySize=512m \
     -XX:MaxMetaspaceSize=256m -Xss512k -XX:NativeMemoryTracking=summary -jar app.jar

• Use NMT to find the largest non-heap consumer; cap it explicitly.
• Reduce thread counts; tune MALLOC_ARENA_MAX.

Use the Foreign Function and Memory API (preview in 21, final in 22): look up the symbol, create a downcall handle, and allocate arguments in an Arena. jextract can generate Java bindings from the header.

jextract --output src -t com.acme.zlib zlib.h
java --enable-preview --enable-native-access=ALL-UNNAMED --source 21 Main.java

• No C compilation step is needed; memory safety checks apply to segments, not to the C library's own bugs.
• Close the Arena to free off-heap memory deterministically.

jlink includes only the modules you list or that are resolved from your module graph. Missing requires java.sql, or services/reflection-only dependencies that static analysis cannot see, produce missing modules at runtime.

jdeps --print-module-deps --ignore-missing-deps app.jar
jlink --add-modules java.base,java.sql,jdk.unsupported --output rt --strip-debug --compress zip-6

• Add modules used via reflection, ServiceLoader or JNDI manually (--add-modules).
• Spring Boot apps often need jdk.unsupported, java.naming, java.management.

In a named module the consumer needs uses <service> and the provider needs provides <service> with <impl> in its module-info.java; the META-INF/services file is only honored on the classpath or in automatic modules.

// consumer
module app { uses com.acme.spi.Tax; }
// provider
module vat { provides com.acme.spi.Tax with com.acme.vat.VatTax; }

• Provider must also be resolved into the module graph (--add-modules or required).
• The service interface package must be exported.

If the method both reads and writes, a wildcard is the wrong tool; use a type parameter. If it only reads use ? extends, if it only writes use ? super.

static double sum(List<? extends Number> xs) { double s = 0; for (Number n : xs) s += n.doubleValue(); return s; }
static void fill(List<? super Integer> out) { for (int i = 0; i < 3; i++) out.add(i); }
static <T> void swap(List<T> l, int i, int j) { T t = l.get(i); l.set(i, l.get(j)); l.set(j, t); }

• Wildcard capture helpers allow List<?> signatures to call generic implementations.
• Return types should rarely be wildcards.

true for 127 and false for 1000 on a default JVM, because Integer.valueOf caches -128..127 and returns distinct objects beyond.

Integer a = 127, b = 127;
Integer c = 1000, d = 1000;
System.out.println(a == b);       // true
System.out.println(c == d);       // false
System.out.println(c.equals(d));  // true

• -XX:AutoBoxCacheMax=2000 would flip the second to true; never rely on it.
• Always compare boxed values with equals or unbox.

Every Long above 127 allocates. Switch to a primitive-specialized map (fastutil Object2LongOpenHashMap, Eclipse Collections), or hold a mutable accumulator: Map<String, LongAdder> or long[] slot.

Map<String, long[]> m = new HashMap<>();
m.computeIfAbsent(key, k -> new long[1])[0] += delta;

• Measure with JMH -prof gc to see B/op before and after.
• Avoid premature optimization if allocation rate is small.

Not necessarily. High allocation rate with short young pauses is healthy generational behaviour, provided survivors die and promotion is low. It becomes an issue when GC CPU share is high, young gen is too small causing premature promotion, or pauses breach SLOs.

• Check GC time percentage, promotion rate, survivor occupancy and old growth.
• Reduce allocation with JFR allocation profiling (boxing, string building, temp collections).
• Increasing young generation size reduces frequency at the expense of per-GC work.

Use Cleaner with a static nested cleanup action that holds only the native handle (not the owner), and provide AutoCloseable for deterministic release.

final class NativeRes implements AutoCloseable {
    private static final Cleaner CLEANER = Cleaner.create();
    private record State(long handle) implements Runnable { public void run() { free(handle); } }
    private final Cleaner.Cleanable cleanable;
    NativeRes(long h) { cleanable = CLEANER.register(this, new State(h)); }
    @Override public void close() { cleanable.clean(); }  // idempotent
    private static void free(long h) { /* native free */ }
}

• If State were an inner class referencing NativeRes, the object would never become phantom reachable.
• clean() runs at most once.

Pool threads are reused. If the value is not removed after a request, the next request on that thread sees stale data (a security bug) and the value stays reachable (a leak).

static final ThreadLocal<User> CURRENT = new ThreadLocal<>();
void handle(Req r) {
    CURRENT.set(auth(r));
    try { process(r); } finally { CURRENT.remove(); }
}

• Put cleanup in a servlet Filter/interceptor finally.
• InheritableThreadLocal copies to child threads at creation, and does not follow pool-reused threads.
• Asynchronous hand-off requires explicit context propagation.

Deduplication shares only the underlying byte[] of strings that survive a few GCs (age threshold), and runs concurrently in the background. It does not dedup String objects themselves nor short-lived strings, and has no effect if the duplicates are not strings or the bytes are tiny.

• Observe with -Xlog:stringdedup*=debug.
• Better wins come from avoiding duplication at the source (interning controlled sets, enums, canonical maps).
• Supported by G1, ZGC (generational), Shenandoah, Parallel and Serial in recent JDKs.

Parallel's full pause scales with live data. Move to a concurrent collector: G1 first (Full GC avoided, pauses ~200ms), ZGC or Shenandoah if you need < 10ms. Validate under load, compare throughput loss, memory overhead and CPU.

java -XX:+UseZGC -XX:+ZGenerational -Xmx64g -Xlog:gc*:file=zgc.log -jar app.jar

• Heaps above 32GB lose compressed oops; ZGC does not use them anyway.
• Alternatively split the batch and the request-serving workloads into separate JVMs.

Not necessarily. Threads blocked in native I/O such as socketRead0 are reported RUNNABLE by the JVM, because it does not distinguish them from running Java code. They are waiting on the network, typically a slow downstream, without timeout.

• Verify with top -H and per-thread CPU time.
• Fix: set connect/read timeouts, use circuit breakers and bulkheads, and monitor pool saturation.
• JFR jdk.SocketRead events show durations and hosts.

Deoptimization: a speculative assumption (type profile, class hierarchy, null/range check, uncommon trap) failed, so compiled code was invalidated ("made not entrant") and execution fell back to the interpreter until recompiled. Occasional events are normal; repeated cycles hurt performance.

• Typical triggers: a new subclass loaded changing a monomorphic call site, a branch never taken before now executed.
• Inspect with -XX:+UnlockDiagnosticVMOptions -XX:+LogCompilation or JFR jdk.Deoptimization.
• Mitigate by warming with representative traffic and avoiding megamorphic hot paths.

When the code cache fills, the JIT disables compilation ("CodeCache is full. Compiler has been disabled"), so new hot code runs interpreted, producing a drastic slowdown and CPU rise.

• Increase -XX:ReservedCodeCacheSize (default 240MB with tiered compilation).
• Code cache sweeping/flushing exists but cannot always cope with heavy dynamic class generation.
• Monitor with jcmd <pid> Compiler.codecache and the JMX Code Cache pool.

Write a JMH benchmark for the hot path and use the GC profiler, which reports normalized allocation per operation (gc.alloc.rate.norm) independent of speed. Compare before and after with several forks.

java -jar benchmarks.jar ParseBench -prof gc -f 3 -wi 5 -i 5

• Confirm in production with JFR allocation events (jdk.ObjectAllocationSample).
• B/op near 0 may indicate the JIT elided the work or scalar-replaced it; check the result is consumed.