C#.NET — Which statement about the garbage collector (GC) is correct?

Introduction / Context:
The .NET GC manages each process's managed heap, automatically reclaiming memory for objects that are no longer reachable. Understanding its scope and triggers is key to writing efficient managed code.

Given Data / Assumptions:

• We are discussing GC behavior at the process level.
• Reachability, not reference count, determines collection.

Concept / Approach:
Each managed process hosts its own garbage collector instance responsible for that process's heaps. Objects are eligible for collection when they are unreachable (no live roots). The GC runs automatically based on allocation pressure and heuristics; manual invocation via GC.Collect() is possible but usually discouraged.

Step-by-Step Solution:

Verification / Alternative check:
Review runtime architecture: each process's CLR hosts GC and heaps; task manager shows independent processes with independent heaps.

Why Other Options Are Wrong:

• B: Contradicts process isolation.
• C: Confuses reference counting with tracing GC.
• D: Unrelated to application lifecycle.

Common Pitfalls:
Assuming GC uses reference counting like COM; .NET uses tracing and generations.

Final Answer:
There is one garbage collector per program (managed process).