Goals & Key Concepts
Memory allocation for objects, primitives, references
Visibility & lifetime of data across threads and calls
Automatic reclamation via Garbage Collection (GC)
Performance trade-offs
Allocation rate vs GC frequency
Memory footprint vs pause times
Memory management balances correctness (lifetime/visibility) and performance (throughput/latency/footprint).
JVM Memory Areas (Runtime Data Areas)
Heap
Purpose
Stores almost all objects and arrays
Structure (HotSpot typical)
Young Generation
Eden
Most new objects allocated here (fast bump-pointer allocation)
Survivor Spaces (S0/S1)
Objects surviving minor GCs are copied between survivor spaces
Aging increases each GC; eventually promoted
Minor GC (Young GC)
Collects young generation frequently
Often stop-the-world (STW) but short
Old Generation (Tenured)
Stores long-lived objects promoted from young gen
Collected less frequently (Major/Old GC)
Humongous/Large Objects (collector-dependent)
G1: humongous allocations may go directly into special regions
Large objects can increase fragmentation and trigger earlier GC
Allocation & Promotion
TLAB (Thread-Local Allocation Buffer)
Per-thread fast allocation to reduce contention
Escape analysis & scalar replacement
Some objects may be stack-allocated or eliminated by JIT when they do not escape
Promotion rules
Age threshold (tenuring threshold) based on survivor space pressure
Allocation guarantee / promotion failure can trigger full GC (collector-dependent)
Common issues
OutOfMemoryError: Java heap space
Memory leaks (unintended retention through references)
Fragmentation (especially with non-compacting collectors or large objects)
Java Stack (per-thread)
Purpose
Stores stack frames for method calls
Stack Frame contents
Local variables (primitives and references)
Operand stack (bytecode execution)
Return address / bookkeeping
Characteristics
Each thread has its own stack; not shared
Memory reclaimed automatically when frames pop (method returns)
Errors
StackOverflowError (deep recursion, very large frames)
OutOfMemoryError: unable to create new native thread (often related to stack size + native limits)
Method Area (JVM specification concept)
What it stores
Class metadata (fields, methods, interfaces)
Method/constructor bytecode
Static variables (class variables)
HotSpot implementation: Metaspace (Java 8+)
Metaspace lives in native memory (not heap)
Controlled by MaxMetaspaceSize (optional cap)
Common issues
OutOfMemoryError: Metaspace
Excessive class loading / classloader leaks (common in app servers, plugins)
PC Register (per-thread)
Purpose
Holds the address of the currently executing JVM instruction
Notes
Essential for thread switching and resuming execution
Native Method Stack
Purpose
Supports JNI/native calls (C/C++)
Issues
Native memory leaks, crashes outside JVM control
Object Model & Reference Types
Object components (conceptual)
Header (mark word, class pointer) + instance fields + padding/alignment
Reference categories (java.lang.ref)
Strong references
Default; prevent GC as long as reachable
Soft references
Cleared under memory pressure (useful for caches; behavior GC-dependent)
Weak references
Collected at next GC cycle when only weakly reachable
Phantom references
Enqueued after finalization eligibility; used for post-mortem cleanup tracking
Reachability (GC roots to objects)
Soft/weak/phantom reachable
Unreachable (eligible for reclamation)
GC Roots (Where reachability starts)
Thread stacks
Local variables in stack frames
Static fields
Loaded classes’ static references
JNI references
Global/local native handles
JVM internal references
Class metadata, system classloader, interned strings (implementation-dependent), etc.
Notes
Objects not reachable from GC roots are candidates for collection
Garbage Collection Fundamentals
What GC does
Finds unreachable objects
Optionally compacts memory to reduce fragmentation
Stop-the-World (STW) pauses
Some phases require pausing application threads (mutators)
Modern collectors reduce pause times via concurrency and incremental phases
Key metrics
Throughput (% time running application vs GC)
Footprint (extra memory needed for GC structures)
Typical GC events
Mixed GC (G1: young + selected old regions)
Full GC (often compaction + class unloading; most disruptive)
Core GC Algorithms
Mark-Sweep
Cons: fragmentation; may require compaction later
Mark-Compact
Compact live objects to remove fragmentation
Pros: reduces fragmentation
Cons: moving objects costs time; requires updating references
Copying (Semispace)
Copy live objects from from-space to to-space
Pros: fast allocation; no fragmentation in copied area
Cons: requires extra memory; best for young gen with high death rate
Generational hypothesis
Separating young/old improves efficiency
Collectors (HotSpot Overview)
Serial GC
Best for small heaps / single-core / simplicity
Parallel GC (Throughput collector)
Multi-threaded STW young/old collection
Prioritizes throughput over low pauses
CMS (Concurrent Mark Sweep) (legacy/deprecated in newer JDKs)
Mostly concurrent old-gen collection
Issues: fragmentation, concurrent mode failure leading to Full GC
G1 GC (Garbage-First)
Heap divided into regions (young/old mixed)
Mixed collections choose regions with most garbage
Goals: predictable pause targets (soft goal)
Humongous objects handled specially
Performs concurrent marking; uses remembered sets
ZGC (low-latency)
Concurrent, region-based, colored pointers (implementation detail)
Very low pause times, scales to large heaps
Trades memory overhead for latency
Shenandoah (low-latency)
Targets low pause times similar to ZGC
Choosing a collector
Latency-sensitive: ZGC/Shenandoah/G1
Throughput-focused: Parallel
Consider JDK version, heap size, pause requirements, CPU budget
Collector choice is primarily an SLA decision (latency vs throughput) constrained by heap size, CPU, and JDK availability.
Important GC Mechanisms
Write barriers
Small snippets of code executed on pointer updates
Used to maintain remembered sets / card tables for generational GC
Remembered sets / Card marking
Track cross-generation references (old → young)
Enables collecting young gen without scanning entire old gen
SATB (Snapshot-At-The-Beginning) (used by G1 and some others)
Helps concurrent marking by treating certain changes as still-live
Concurrent marking and remark
Concurrent mark phase runs with application
Remark often STW to finalize marking and handle changes
Class unloading
Unloading unused classes when their classloader is unreachable
Often tied to concurrent cycles or full GC, depending on collector
Typical Lifecycle of Objects (Generational GC)
Survive a young GC → copied to Survivor
Promotion to old gen when:
Age exceeds threshold, or
Survivor space pressure triggers early promotion
Long-lived in old gen until old/mixed/full GC reclaims it
Memory Tuning & Configuration (Common Options)
Heap sizing
-Xms (initial heap), -Xmx (max heap)
Balance: too small → frequent GCs; too large → longer marking/compaction and higher footprint
Young gen sizing (collector-dependent)
-Xmn or NewRatio (legacy; not always honored by all collectors)
Goal: match allocation rate and desired minor GC frequency
Metaspace
-XX:MaxMetaspaceSize (cap), -XX:MetaspaceSize (initial trigger)
Direct / native memory
-XX:MaxDirectMemorySize (NIO direct buffers)
Collector selection & goals
-XX:+UseG1GC / +UseZGC / +UseShenandoahGC / +UseParallelGC / +UseSerialGC
G1 pause goal: -XX:MaxGCPauseMillis (soft target)
Common Problems & Diagnostics
OutOfMemoryError categories
Java heap space (heap exhausted)
GC overhead limit exceeded (too much time in GC with little reclaimed)
Metaspace (class metadata exhaustion)
Direct buffer memory (off-heap NIO)
unable to create new native thread (native/OS limits, stacks)
Memory leak patterns
Static collections holding objects indefinitely
ThreadLocal not cleared in thread pools
Caches without eviction/size limits
Listener/observer references not removed
Classloader leaks (redeployments)
GC log analysis (high-level)
Look for:
Increasing old-gen occupancy after GCs (leak suspicion)
Promotion failures or to-space exhausted (G1)
Tools (typical)
jcmd, jstat, jmap (heap dump), jstack
JFR (Java Flight Recorder)
VisualVM / Eclipse MAT (leak analysis)
Best Practices
Prefer clear ownership/lifetimes; avoid accidental retention
Use bounded caches (size/time-based eviction)
Be careful with ThreadLocal in pooled threads (remove when done)
Avoid creating excessive short-lived garbage in hot loops (e.g., unnecessary boxing)
Tune only after measuring (GC logs + profiling)
Choose GC based on SLAs (latency vs throughput) and test under realistic load
Wondershare EdrawMind
