If you’re learning Java, you’ve probably heard people talk about Heap, Stack, and Garbage Collection.
At first, these terms can feel a little confusing.
You might wonder:
Where are Java objects actually stored?
What happens when an object is no longer needed?
Who frees memory in Java?
And why does Java sometimes pause to perform Garbage Collection?
Don’t worry. Java handles most memory management automatically, but understanding what happens behind the scenes is important for writing efficient and reliable applications.
In this guide, we’ll break down Java memory management, the heap, stack, Metaspace, object creation, garbage collection, memory leaks, and common GC concepts in a beginner-friendly way.
What Is Memory Management?
Every program needs memory to store things while it is running.
For example, a Java application may need memory for:
- Objects
- Variables
- Method calls
- Arrays
- Class information
- Temporary data
Java’s JVM (Java Virtual Machine) manages much of this memory for you.
Instead of manually allocating and freeing memory like you might in languages such as C or C++, Java automatically manages object memory through the JVM and its Garbage Collector.
Conceptually:
Java Application
↓
JVM
↓
Memory Management
↓
Heap + Stack + Metaspace + Other Areas
How Does Java Memory Work?
The JVM divides memory into several important areas.
A simplified view looks like this:
JVM Memory
│
├── Heap
│ └── Objects
│
├── Stack
│ └── Method calls & local variables
│
├── Metaspace
│ └── Class metadata
│
└── Other JVM/Native Memory
For beginners, the three areas you should understand first are:
- Heap
- Stack
- Metaspace
Let’s look at each one.
What Is the Heap?
The Heap is the main memory area where Java objects and arrays are allocated.
For example:
User user = new User();
The object created by:
new User();
is allocated on the heap.
Conceptually:
Heap
┌─────────────────────────┐
│ User Object │
│ │
│ name = "John" │
│ age = 25 │
└─────────────────────────┘
The variable user holds a reference to that object.
What Is the Stack?
Each thread in a Java application has its own stack.
The stack is used for things such as:
- Method call frames
- Local variables
- References to objects
- Intermediate values
For example:
public void greet() {
String name = "John";
System.out.println(name);
}
When greet() runs, Java creates a stack frame for the method.
Conceptually:
Stack
┌──────────────────────┐
│ greet() │
│ name → String object │
└──────────────────────┘
When the method finishes, its stack frame is removed.
Heap vs Stack
This is one of the most important concepts to understand.
Consider:
User user = new User();
A simplified mental model is:
Stack Heap
user ─────────────────→ User Object
↓
fields
The variable user is a local reference associated with the current stack frame, while the User object itself is allocated on the heap.
This distinction becomes important when learning Garbage Collection.
What Is Metaspace?
Another important memory area is Metaspace.
Metaspace stores JVM class metadata, such as information related to loaded classes.
For example, when your application loads a class:
class User {
}
the JVM needs memory to keep information about that class.
In modern Java versions, this class metadata is stored in Metaspace, which uses native memory rather than being part of the Java heap.
What Happens When You Create an Object?
Consider:
User user = new User();
A simplified sequence is:
new User()
↓
JVM allocates object memory
↓
Object is created on Heap
↓
Reference is assigned to user
Conceptually:
Stack Heap
user ───────────────→ User Object
As long as the object remains reachable, the JVM considers it potentially useful.
What Happens When an Object Is No Longer Needed?
Now imagine:
User user = new User();
user = null;
The object previously referenced by user may now be unreachable if there are no other references to it.
Conceptually:
Before:
user ─────→ User Object
After:
user → null
User Object
↓
No reachable reference
That object becomes eligible for garbage collection.
Notice the wording:
Eligible for Garbage Collection
It does not mean the object is immediately deleted.
The Garbage Collector decides when to reclaim its memory.
What Is Garbage Collection?
Garbage Collection (GC) is the JVM’s automatic process for reclaiming memory occupied by objects that are no longer reachable by the application.
In simple terms:
Create Object
↓
Use Object
↓
Object Becomes Unreachable
↓
Garbage Collector
↓
Memory Can Be Reclaimed
This is one of the biggest advantages of Java.
You generally don’t need to manually free every object.
How Does the Garbage Collector Know What to Remove?
A simplified way to think about Garbage Collection is through reachability.
Imagine:
Application Root
↓
Object A
↓
Object B
Both objects are reachable.
So they can still be used.
Now imagine:
Application Root
Object A Object B
↓
Object C
If Object B is no longer connected to any GC root and nothing else can reach it, it may become eligible for collection.
Conceptually:
Reachable Object
↓
Keep
Unreachable Object
↓
Collect
What Are GC Roots?
The Garbage Collector starts from certain special references called GC roots.
Examples can include:
- Active thread references
- Local variables in active stack frames
- Static references
- JNI references
The exact implementation details depend on the JVM and collector, but the core idea is:
If an object cannot be reached from the GC roots, it can eventually be reclaimed.
Generational Garbage Collection
Java Garbage Collectors commonly use the idea of generational collection.
The basic assumption is:
Most objects become unreachable relatively soon after they are created.
The heap is therefore conceptually divided into generations.
A simplified model is:
Heap
│
├── Young Generation
│
└── Old Generation
The young generation commonly includes:
Eden
Survivor
Survivor
Conceptually:
New Object
↓
Eden
↓
Survives GC
↓
Survivor Space
↓
Survives More Collections
↓
Old Generation
The exact implementation varies between Garbage Collectors and Java versions.
What Is the Young Generation?
The Young Generation is where newly created objects are typically allocated in generational collectors.
For example:
User user = new User();
The object may initially be allocated in the young generation.
If it becomes unreachable quickly, the JVM can reclaim it during a young-generation collection.
This is efficient because many short-lived objects don’t need to survive for long.
What Is the Old Generation?
Objects that survive multiple collection cycles may eventually be promoted to the Old Generation.
Conceptually:
New Object
↓
Young Generation
↓
Survives
↓
Survives
↓
Old Generation
Long-lived objects may stay in the old generation for a significant amount of time.
What Is a Minor GC?
A collection focused primarily on the young generation is often called a young collection or, in older terminology, a minor GC.
Because young objects are frequently short-lived, these collections can reclaim a lot of memory efficiently.
For example:
Young Generation
Object A → Dead
Object B → Alive
Object C → Dead
Object D → Dead
The collector can reclaim the memory associated with unreachable objects.
What Is a Major or Full GC?
The terminology around major GC and full GC can vary between JVM collectors, so it’s better not to treat them as exact synonyms.
A Full GC generally involves a broader collection of heap regions and can be significantly more expensive than a young-generation collection.
Full GCs may result in longer pauses depending on the collector, heap state, and application workload.
Common Garbage Collectors in Java
Modern Java provides several Garbage Collector implementations.
Some you may encounter include:
G1 Garbage Collector
G1 (Garbage-First) GC is a general-purpose collector designed for large heaps and predictable pause goals.
It divides the heap into regions rather than relying on one large contiguous young/old layout.
Z Garbage Collector
ZGC is designed for very low pause times, including applications with large heaps.
Shenandoah
Shenandoah GC also focuses on reducing pause times by doing more work concurrently.
Serial GC
The Serial Collector uses a single GC thread for collection work and can be suitable for smaller applications or environments where simplicity matters.
The best collector depends on the application, heap size, latency requirements, and JVM version.
Does Garbage Collection Stop the Application?
Garbage Collection can involve stop-the-world pauses, where application threads are temporarily paused.
However, modern collectors perform significant amounts of GC work concurrently with application execution.
Conceptually:
Application
──────────────────────
GC
────────
Some phases may happen while the application continues running, while others may require pauses.
The duration and frequency of pauses depend on factors such as:
- Garbage Collector
- Heap size
- Allocation rate
- Number of live objects
- Application workload
- JVM configuration
What Is a Memory Leak in Java?
You might think:
“Java has Garbage Collection, so memory leaks can’t happen.”
Unfortunately, that’s not true.
Java can still have memory leaks.
A memory leak can happen when your application accidentally keeps references to objects that it no longer needs.
For example:
static List<User> users = new ArrayList<>();
If you continuously add objects:
users.add(new User());
and never remove them, the list continues to hold references to those objects.
From the Garbage Collector’s perspective, those objects are still reachable.
Therefore, they cannot be reclaimed.
Conceptually:
Application
↓
Static List
↓
User
User
User
User
User
...
The problem isn’t that GC failed.
The problem is that the application is still holding references to objects it no longer needs.
Common Causes of Memory Leaks
Some common causes include:
Static Collections
static List<Object> cache = new ArrayList<>();
If the collection grows without limits, memory usage can continuously increase.
Unbounded Caches
A cache that never removes old entries can consume large amounts of memory.
Listeners and Callbacks
Objects may remain referenced because listeners weren’t properly removed.
Long-Lived Objects
Objects with long lifetimes can accidentally retain references to large object graphs.
ThreadLocal Usage
Incorrect use of ThreadLocal in long-lived threads can sometimes retain data longer than intended.
StackOverflowError vs OutOfMemoryError
These two errors are often confused.
StackOverflowError
This usually happens when the thread stack runs out of space.
A common cause is infinite recursion:
public void test() {
test();
}
The method keeps calling itself:
test()
↓
test()
↓
test()
↓
...
Eventually, the stack can overflow.
OutOfMemoryError
OutOfMemoryError means the JVM cannot satisfy a memory allocation request.
It can happen for different reasons, such as:
- Heap exhaustion
- Metaspace exhaustion
- Native memory exhaustion
- Excessive memory usage
A memory leak is one possible cause, but not the only one.
Can We Force Garbage Collection?
You may see code like:
System.gc();
This requests that the JVM perform garbage collection.
But remember:
It is only a request, not a command.
The JVM is free to decide whether and when to perform GC.
You generally should not rely on System.gc() as part of normal application logic.
What Is Object Eligibility?
An object is eligible for Garbage Collection when it is no longer reachable from the application’s GC roots.
For example:
User user = new User();
user = null;
If there are no other references to the object, it may become eligible for collection.
But:
Eligible for GC
≠
Immediately deleted
The JVM decides when to reclaim the memory.
Strong References
Most normal Java references are strong references.
For example:
User user = new User();
As long as user is reachable, the object is strongly reachable and won’t be collected.
Java also provides other reference types, such as:
- Soft references
- Weak references
- Phantom references
These are more advanced concepts and are mainly useful for specialized memory-sensitive designs.
Why Should Developers Understand Memory Management?
You might be thinking:
“If Java manages memory automatically, why do I need to understand it?”
Because understanding memory helps you diagnose problems such as:
OutOfMemoryError- Excessive garbage collection
- Slow applications
- Large object retention
- Memory leaks
- Unexpected performance issues
It also helps you write better code.
For example, if you understand object lifetime, you’ll be less likely to create an unbounded cache accidentally.
How to Reduce Memory Problems
Here are some practical tips.
1. Avoid Unbounded Collections
Don’t let lists, maps, or caches grow forever.
2. Remove Unused References
If an object should no longer be retained, make sure long-lived objects aren’t still referencing it.
3. Be Careful with Caches
Use appropriate cache eviction strategies.
4. Avoid Creating Unnecessary Objects
Excessive temporary object creation can increase allocation and GC pressure.
5. Monitor Memory Usage
For production applications, monitor:
- Heap usage
- GC activity
- Allocation rate
- Pause times
- Thread count
6. Profile Before Optimizing
Don’t randomly change JVM memory settings.
First understand where the memory is actually being used.
Java Memory Management in One Diagram
Here’s a simple mental model:
JVM Memory
│
┌─────────────┼─────────────┐
↓ ↓ ↓
Heap Stack Metaspace
│ │ │
Objects Method calls Class metadata
│
↓
Garbage Collection
│
↓
Unreachable objects reclaimed
Remember that this is a simplified model. The JVM also uses other memory areas and native resources.
The Complete Object Lifecycle
Let’s put everything together.
When you write:
User user = new User();
a simplified lifecycle looks like:
Create Object
↓
Allocate Memory
↓
Object Lives on Heap
↓
Application Uses Object
↓
Object Becomes Unreachable
↓
Object Becomes Eligible for GC
↓
Garbage Collector Finds It
↓
Memory Is Reclaimed
That’s the basic lifecycle you should understand.
Final Thoughts
Java’s automatic memory management is one of the reasons developers can focus more on application logic instead of manually freeing every object.
But automatic memory management doesn’t mean you can completely ignore memory.
The key concepts to remember are:
Heap → Stores objects and arrays
Stack → Stores method frames and local data for each thread
Metaspace → Stores class metadata
Garbage Collector → Reclaims memory from unreachable objects
And remember one of the most important points:
Garbage Collection removes unreachable objects, not objects that your application simply doesn’t “need” anymore.
If your application still holds a reference to an object, the Garbage Collector generally considers that object reachable.
Once you understand heap vs stack, object reachability, GC roots, generations, and memory leaks, Java memory management becomes much easier to reason about.
From there, you can move into more advanced topics such as G1 GC, ZGC, JVM tuning, heap dumps, GC logs, and memory profiling.
