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.