Garbage Collection Explained

Why should you care?

When a program creates objects, those objects need memory.

For example:

Person user = new Person();

At some point, the program may stop using that object.

The question is:

Who gets that memory back?

In languages with garbage collection, the runtime can automatically identify objects that are no longer reachable and reclaim their memory.

This removes a huge amount of manual memory-management work from the programmer.

But garbage collection is not magic.

It has rules, costs, and limitations.

The Problem

Imagine a program continuously creates objects:

for (int i = 0; i < 1000000; i++) {
    new Person();
}

If memory were never reclaimed:

Create object
    ↓
Use memory
    ↓
Create another object
    ↓
Use more memory
    ↓
Repeat
    ↓
Memory exhausted

The program would eventually run out of memory.

A garbage collector solves this by finding objects that are no longer reachable.

Object created
      ↓
Program uses object
      ↓
Object becomes unreachable
      ↓
Garbage Collector
      ↓
Memory can be reclaimed

The Concept

The key concept behind garbage collection is reachability.

An object is generally considered alive if it can still be reached from a set of GC roots.

Conceptually:

GC Root
   ↓
Object A
   ↓
Object B

Both A and B are reachable.

Now suppose:

GC Root
   ↓
Object A

Object B
   ↓
Object C

If nothing can reach B or C anymore:

B → C

they are unreachable.

The garbage collector can eventually reclaim their memory.

Simple Explanation

Think of a city full of houses.

Some houses are still connected to the road system.

Road
 ↓
House A
 ↓
House B

These houses are reachable.

Now imagine another group of houses:

House C
 ↓
House D

but there is no road connecting them to the city.

They are disconnected from the usable network.

Garbage collection works similarly.

It asks:

Can this object still be reached from something the program considers alive?

If not, the object may be garbage.

Real-world Analogy

Imagine a hotel.

Guests check into rooms:

Guest → Room

When a guest leaves and nobody else is using the room:

Room → Empty

The hotel staff eventually identifies empty rooms and makes them available again.

Garbage collection does something conceptually similar:

Object created
      ↓
Object reachable
      ↓
Object no longer reachable
      ↓
Garbage collector detects it
      ↓
Memory reclaimed

The garbage collector is essentially the memory-management system that cleans up objects that are no longer needed.

Code Example

Consider Java:

public class Main {

    public static void main(String[] args) {

        Person user = new Person();

        user = null;
    }
}

Initially:

user
 ↓
Person Object

After:

user = null;

we have:

user
 ↓
null

Person Object
     ↑
     │
No reference

If there are no other references to that object, it 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 and how reclamation occurs.

Garbage Collection Is Not free()

In C, programmers commonly manage memory manually:

int *p = malloc(sizeof(int));

/* use memory */

free(p);

The programmer explicitly releases the memory.

In Java:

Person p = new Person();

you normally do not write:

free(p)

Instead, the runtime determines when the object is no longer reachable and can reclaim its memory.

So:

Manual Memory Management
→ Programmer controls deallocation

Garbage Collection
→ Runtime manages reclamation

How Does the Garbage Collector Know?

A common conceptual approach is tracing garbage collection.

The collector starts from GC roots.

Examples of roots can include:

Active local references
Static references
Thread-related references
Runtime-managed references

The exact root set depends on the runtime.

Then it follows references:

Root
 ↓
Object A
 ↓
Object B

Anything reachable is considered live.

Anything not reachable is a candidate for reclamation.

Conceptually:

          Root
         /    \
        ↓      ↓
      Obj A  Obj B
        ↓
      Obj C

      Obj D
        ↓
      Obj E

Here:

A, B, C
→ Reachable

D, E
→ Unreachable

D and E can potentially be reclaimed.

Mark and Sweep

One classic garbage collection technique is Mark-and-Sweep.

Mark

Start from the roots and mark every reachable object.

Root
 ↓
A ✓
 ↓
B ✓

C

C is not reachable.

Sweep

The collector identifies unmarked objects and reclaims their memory.

A ✓
B ✓
C ✗ → reclaim

Conceptually:

Mark
 ↓
Identify reachable objects
 ↓
Sweep
 ↓
Reclaim unreachable objects

This is one of the fundamental ideas behind tracing garbage collection.

What About Cycles?

This is an important advantage of reachability-based garbage collection.

Consider:

A → B
↑   ↓
└───┘

A and B reference each other.

But suppose nothing else references A.

Then:

GC Root
   ↓
nothing

A ↔ B

The objects are unreachable even though they reference each other.

A reference-counting system can struggle with such cycles because both objects still have nonzero reference counts.

A tracing collector can identify that neither is reachable from the roots and reclaim them.

Generational Garbage Collection

Modern garbage collectors often use the observation that:

Most objects die young.

For example:

Temporary object
     ↓
Used briefly
     ↓
No longer needed

So collectors may divide objects into generations or regions based on age.

A simplified model:

Young Generation
       ↓
Short-lived objects

Survivors
       ↓
Older Generation

Long-lived objects

The exact design differs between garbage collectors.

The goal is to avoid repeatedly scanning every object in the heap.

Why Young Objects Matter

Imagine:

for (int i = 0; i < 1000000; i++) {
    String temp = createTemporaryString();
}

Many temporary objects may become unreachable very quickly.

Instead of treating all objects equally, a generational collector can focus collection work on areas where garbage is expected to be abundant.

This can improve efficiency.

Garbage Collection Pauses

Garbage collection itself requires computation.

At certain points, the runtime may need to:

Identify objects
Update metadata
Move objects
Reclaim memory
Adjust references

Some collectors may temporarily pause application threads for certain phases.

This can produce GC pauses.

For a normal desktop application, a small pause may not matter.

For a:

High-frequency trading system
Game
Real-time application
Large backend service

latency can matter significantly.

Modern garbage collectors therefore use sophisticated techniques to reduce pause times.

Common Mistakes

Mistake 1: Thinking garbage collection happens immediately

Consider:

Person p = new Person();
p = null;

The object may become eligible for collection.

It does not mean the garbage collector immediately frees it.

The runtime decides when collection occurs.

Mistake 2: Thinking garbage collection prevents all memory problems

It does not.

You can still accidentally retain references:

static List<Object> cache = new ArrayList<>();

If objects are continuously added and never removed:

Cache
 ↓
Object
Object
Object
Object
...

The objects remain reachable.

The garbage collector cannot reclaim them simply because the program no longer logically needs them.

This can result in a memory leak.

Mistake 3: Thinking System.gc() guarantees collection

In Java:

System.gc();

is only a request or hint to the runtime.

It does not guarantee that garbage collection will immediately happen.

Mistake 4: Thinking garbage collection deletes objects

The important concept is memory reclamation.

The runtime determines that an object is unreachable and makes its storage available for reuse.

The language-level object itself is not necessarily "deleted" in the simple sense people often imagine.

Advanced Notes

Stop-the-world Collection

Some garbage collection phases may temporarily stop application threads.

Conceptually:

Application
    ↓
Pause
    ↓
GC work
    ↓
Resume

This is called a stop-the-world pause.

Not every GC operation necessarily requires the entire application to stop, and modern collectors perform significant work concurrently.

Concurrent Garbage Collection

Some modern collectors perform parts of garbage collection while application threads continue running.

Conceptually:

Application ───────────────→
GC          ───────────────→

instead of:

Application ─── Pause ──────→
GC               ↑

This can reduce latency, although it introduces additional complexity and overhead.

Object Movement

Some garbage collectors move objects to compact memory.

Imagine:

Before:

┌────┬────┬────┬────┬────┐
│ A  │    │ B  │    │ C  │
└────┴────┴────┴────┴────┘

After compaction:

┌────┬────┬────┬────┬────┐
│ A  │ B  │ C  │    │    │
└────┴────┴────┴────┴────┘

This can reduce fragmentation.

But if an object moves, references to it must remain correct.

The runtime and garbage collector handle this according to the collector's design.

Garbage Collection and References

This connects directly to the previous topic.

Consider:

Person a = new Person();
Person b = a;

Conceptually:

a ──────┐
        ↓
     Person
        ↑
        │
b ──────┘

If:

a = null;

the object is still reachable:

b
 ↓
Person

Therefore, it cannot yet be reclaimed.

Only after all relevant paths from the GC roots disappear can the object become unreachable.

Garbage Collection and Memory Allocation

The complete lifecycle can be visualized as:

Allocation
    ↓
Object created
    ↓
Object used
    ↓
References change
    ↓
Object becomes unreachable
    ↓
Garbage collector detects it
    ↓
Memory reclaimed
    ↓
Memory reused

This is the connection between the previous topic and this one.

Memory allocation gives the program storage.

Garbage collection determines when certain dynamically allocated storage can be reclaimed.

The Bigger Picture

Garbage collection connects several fundamental concepts:

Objects
   ↓
References
   ↓
Reachability
   ↓
Garbage Collection
   ↓
Memory Reclamation
   ↓
Memory Reuse

At the system level:

Application
     ↓
Runtime
     ↓
Garbage Collector
     ↓
Heap
     ↓
Operating System
     ↓
Physical Memory

The programmer works mostly with objects and references.

The runtime handles much of the underlying memory-management complexity.

The Most Important Mental Model

Do not think:

Object becomes unused
        ↓
Immediately deleted

Instead think:

Object becomes unreachable
        ↓
Eligible for collection
        ↓
Garbage collector runs
        ↓
Memory reclaimed

And the key question is:

Can the object still be reached from a live root?

If yes:

Keep it

If no:

It may be reclaimed

Summary

Garbage collection is an automatic memory-management mechanism used by many programming languages and runtimes.

Its fundamental idea is:

Find objects that are no longer reachable
        ↓
Reclaim their memory
        ↓
Reuse that memory

The most important concepts are:

• Reachability determines whether an object is still potentially needed.
• GC roots provide the starting points for reachability analysis.
• Mark-and-sweep is a classic tracing technique.
• Generational collection takes advantage of short-lived objects.
• Compaction can reduce fragmentation.
• GC pauses can affect application latency.
• Garbage collection does not eliminate all memory problems.
• An unreachable object is eligible for collection, not necessarily immediately collected.

The deeper lesson is:

Garbage collection is not about finding objects that the programmer thinks are useless. It is about determining which objects are no longer reachable according to the runtime's rules.

Once you understand reachability, garbage collection stops being a mysterious background process and becomes a logical consequence of how references and object lifetimes work.