Answer

What is Garbage Collection?

Garbage Collection (GC) is Android’s automatic memory janitor.

Its job is simple: find objects in memory that your app no longer uses and free them up so the memory can be reused.

Think of it like:

You just moved into a house (heap). You keep buying stuff (objects).

After a while, your house gets cluttered. GC is the housekeeper who removes things you can’t reach anymore — like that box you stuffed into the attic and forgot existed.

How GC Works in Android (Step-by-Step)

Android uses ART (Android Runtime), which has a generational, mostly concurrent GC.

Here’s the typical lifecycle:

1. Root Set Scan

* GC starts by checking GC Roots:

* Thread stacks

* Static variables

* JNI global refs

* These are like “entry points” into memory that are definitely still alive.

2. Reachability Analysis (Mark Phase)

* ART uses a tricolor marking algorithm:

* White: Objects not yet visited (possibly garbage)

* Gray: Objects to be scanned

* Black: Objects proven alive

* It traverses references (like a graph search) and marks all reachable objects.

3. Sweep/Copy/Compact Phase

* Unmarked (white) objects are freed.

* Live objects may be compacted to avoid fragmentation.

4. Generational Optimization

* Young Generation (Minor GC): Fast, collects short-lived objects (like temporary strings, small data objects).

* Old Generation (Major GC): Collects objects that survived multiple GCs (activities, long-lived caches).

5. Concurrent Execution

* Most of this happens while your app is running to reduce UI pauses.

* Some steps are Stop-The-World (STW) but very short.

Visual Diagram

A[App Allocates Objects] --> B[Heap Fills]

B --> C[GC Triggered]

C --> D[Root Scan]

D --> E[Mark Reachable Objects (Tricolor Marking)]

E --> F[Collect Unreachable Objects]

F --> G[Compact / Reuse Memory]

G --> H[App Continues Smoothly]

When GC Happens

* When heap usage crosses a certain threshold

* When memory pressure is high (e.g., before OutOfMemoryError)

* Explicit hint: System.gc() (just a request, not a guarantee!)

Code Example: Memory Leak & Fix

// Memory leak: Activity reference is never cleared

object SessionManager {

var currentActivity: Activity? = null

}

When Activity is rotated, the old instance stays in memory → GC sees it as still “reachable” → memory leak.

Fix with WeakReference:

object SessionManager {

var currentActivity: WeakReference<Activity>? = null

}

Now GC can reclaim the activity when it’s no longer used.

Real-World Analogy

Think of your heap like a WhatsApp group chat:

* GC Roots = People still in the group

* Reachable objects = People who are still chatting

* Unreachable objects = People who left, no one mentions them anymore → GC removes them from group history.

Interview Tips & Gotchas

* System.gc() should not be used in production. It just requests GC, doesn’t force it.

* Frequent GC events → indicates high allocation churn (optimize code).

* Large heap + Full GC pause → can cause UI jank or ANR if mismanaged.

* Focus on reducing allocations and fixing memory leaks rather than forcing GC.