Memory Management and JVM Internals

JVM Architecture

When you run a Java program, you are not running it directly on the CPU. You are running it inside the Java Virtual Machine, an abstraction layer that makes Java programs portable across operating systems and hardware architectures. The JVM has three major subsystems, and understanding their roles helps you understand nearly every performance and memory characteristic of Java applications.

Heap vs Stack Memory

Java uses two primary memory regions, and the distinction between them is one of the most important concepts in understanding how the runtime behaves.

The stack is per-thread memory. Every time a method is called, the JVM pushes a new frame onto the calling thread's stack. That frame contains the method's local variables and its return address. When the method returns, the frame is popped off and its memory is instantly reclaimed. Stack allocation and deallocation are extremely fast: it is just a pointer increment and decrement. The stack is limited in size (typically a few hundred kilobytes to a few megabytes). Exceeding it, usually by unbounded recursion, produces a StackOverflowError.

The heap is shared across all threads. Every object created with new lives on the heap, as do their instance variables. The heap can grow large (configured with -Xmx), but allocations are slower than stack allocations and objects must eventually be reclaimed by the garbage collector. Variables on the stack that hold object references point into the heap. The variable (the reference) is on the stack; the actual object data is on the heap.

Method Area and Metaspace

Every class loaded into the JVM has metadata: its name, its superclass, its interfaces, the bytecode of its methods, its constant pool (a table of literals, method names, and type references), and information about its fields. All of this must live somewhere in memory. That place is the method area.

In Java 7 and earlier, the method area was implemented as a fixed-size region of the heap called PermGen (Permanent Generation). Its size was configured with -XX:MaxPermSize. When applications loaded many classes or used heavy code generation (ORM frameworks, application servers, dynamic proxies), PermGen would fill up and produce a notoriously unhelpful OutOfMemoryError: PermGen space error.

Java 8 replaced PermGen with Metaspace. The critical difference is location and growth strategy. Metaspace lives in native memory, outside the Java heap. It grows automatically as more classes are loaded. There is no fixed ceiling unless you set one with -XX:MaxMetaspaceSize. Without a limit, the JVM will use as much native memory as the OS allows, which eliminates most PermGen-related errors. Class metadata in Metaspace is garbage collected when the class loader that loaded the class is itself garbage collected, which typically happens with dynamic class loading in OSGi or application server contexts.

Garbage Collection Concepts

Java manages heap memory automatically. You allocate objects; the garbage collector figures out which ones are no longer needed and reclaims their memory. The fundamental question the GC must answer is: which objects are still in use?

The answer is based on reachability. The GC starts from a set of root references: local variables in thread stacks, static fields, and references held by the JVM itself. It traverses all references from those roots, marking every object it can reach. Any object not marked after this traversal is unreachable and eligible for collection. This mark-then-sweep approach is the foundation of all modern GC algorithms.

Java's heap is organized into generations. Most objects die young: you create a temporary list inside a method, the method returns, and the list is immediately garbage. The Young generation collects frequently and quickly. Objects that survive multiple young collections graduate to the Old generation (also called Tenured), which is collected less often with longer pauses. This generational hypothesis, "most objects die young," is what makes GC practical for interactive and server applications.

Strong, Soft, Weak, and Phantom References

Java's default reference is a strong reference: any object reachable through a strong reference will not be collected. But sometimes you want to hold a reference to an object in a way that does not prevent the GC from reclaiming it when memory is needed, or when no other code cares about it. The java.lang.ref package provides three weaker reference types, each with different collection semantics.

Memory Leaks in Java

The common assumption is that garbage collection eliminates memory leaks. It eliminates one kind of leak: forgetting to free allocated memory when you are done with it. Java collects objects automatically, so that particular mistake is impossible. However, a different kind of leak is very much possible: holding a strong reference to an object longer than necessary, preventing the GC from reclaiming it.

From the GC's perspective, an object that you are no longer semantically using but that is still reachable through some reference chain is as alive as one you are actively using. The GC cannot know the difference between "I am still going to use this" and "I forgot to remove this from the list." Memory leaks in Java are therefore really unintentional reference retention.

The symptoms of a leak are gradual heap growth over time, increasing GC pressure and frequency, and eventually an OutOfMemoryError after the application has been running for a while. The longer the application runs, the more memory it uses, even if the number of active objects is stable.

finalize() and System.gc()

The finalize() method was Java's original mechanism for running cleanup code before an object is garbage collected. You could override it in any class and the GC would call it on eligible objects before reclaiming them. In practice it caused more problems than it solved: finalization is unpredictable, objects can be "resurrected" during finalization, the finalizer thread can lag behind the GC and cause a backlog of uncollected objects, and finalization delays the actual memory reclamation by at least one additional GC cycle. It was deprecated in Java 9 and is removed in Java 18. The modern replacement is the Cleaner API or PhantomReference with a ReferenceQueue.

System.gc() is a hint to the JVM that now might be a good time to run garbage collection. The JVM is free to ignore this hint entirely. In production code, calling System.gc() is almost always wrong. It can trigger expensive full GC cycles at unpredictable moments, interfering with the JVM's own carefully tuned collection strategy. The one legitimate use is in performance profiling and benchmarking, where you want the heap in a known state before measuring, and in tests that verify reference collection behaviour.

String Pool and Interning

Strings are the most commonly created objects in most Java applications. To reduce memory usage, the JVM maintains a string pool, also called the string intern pool. When you write a string literal in source code, the compiler stores it in the class's constant pool. At class load time the JVM checks the string pool: if an equal string already exists, both references point to the same object. If not, the string is added to the pool.

This is why the == operator can return true for two string literals but must not be used for general string comparison. Two literal strings with the same content share a pooled object, but a string created with new String("hello") always creates a new heap object outside the pool. This is also why you should always compare strings with equals(): it compares the character content, not the object identity.

The String.intern() method manually adds a string to the pool. If the pool already contains an equal string, the pooled reference is returned. Calling intern() on a string created at runtime puts it in the pool so future comparisons with == work. In Java 7 the string pool was moved from PermGen into the main heap, so interned strings are subject to normal GC. In Java 8+, Metaspace handles class metadata but the string pool is still on the heap.

JVM Tuning Basics

The JVM has sensible defaults that work for most applications, but long-running server applications, high-throughput batch jobs, and latency-sensitive systems often benefit from explicit tuning. All JVM options are passed on the command line at startup and fall into three categories: standard options (-), non-standard options ( -X), and advanced options ( -XX). The non-standard and advanced options are JVM-specific and can change between versions.

Quiz - Test Your Knowledge

Ten questions covering the JVM architecture, heap and stack memory, Metaspace, garbage collection algorithms and stop-the-world pauses, reference types, memory leaks, the string pool and interning, and JVM tuning flags. Read each option carefully before selecting your answer.