Build fluency in the vocabulary of a runtime automatically reclaiming memory no reference points to.
0 / 5 completed
1 / 5
At standup, a dev mentions a runtime automatically identifying objects no longer reachable from any live reference and reclaiming their memory, without the developer ever calling a free or delete function. What is this process called?
Garbage collection is the runtime automatically identifying objects no longer reachable from any live reference, such as a local variable or a static field, and reclaiming their memory without the developer ever having to call a free or delete function themselves. A memory leak is the opposite failure, where memory that should be reclaimed never is. This automatic reclamation is what frees a developer from manually tracking every allocation's lifetime, at the cost of the runtime needing to pause or interleave collection work with the program's own execution.
2 / 5
During a design review, the team picks a generational garbage collector that scans young, short-lived objects far more often than older, long-lived ones. Which capability does this design provide?
A generational collector provides faster typical collection cycles, since empirically most objects die young, so frequently scanning just the small young generation reclaims the bulk of garbage cheaply, while the larger, more stable old generation is scanned far less often. Scanning the entire heap in full on every cycle would waste time repeatedly re-examining long-lived objects that were never going to be garbage anyway. This generational assumption is one of the most impactful optimizations behind modern garbage collector performance.
3 / 5
In a code review, a dev notices an event listener is registered on a long-lived object but is never removed when the shorter-lived component that registered it is done with it, keeping that component reachable indefinitely. What does this represent?
This is a logical memory leak, and it can happen even in a garbage-collected language, since the collector is only reclaiming what's unreachable, and a forgotten event listener registered on a long-lived object keeps the shorter-lived component reachable, and therefore un-reclaimable, indefinitely. A deadlock is an unrelated concurrency concept about blocked threads, not about object reachability. This is exactly why garbage collection prevents dangling-pointer bugs but doesn't prevent a program from accidentally holding onto references it should have released.
4 / 5
An incident report shows a long-running server's memory usage climbed steadily until it crashed, even though the garbage collector was running normally, because a growing list kept accumulating references to objects that were otherwise done being used. What practice would prevent this?
Explicitly removing or unsubscribing a reference, such as clearing entries from the growing list or unregistering an event listener once its referenced objects are actually done being used, is what lets the garbage collector reclaim that memory, since the collector can only reclaim what's unreachable. Continuing to let the list accumulate references indefinitely is exactly what caused the steady memory growth and eventual crash in this incident, since the garbage collector correctly refuses to reclaim memory it can still trace a live reference to. This explicit-release discipline is required even in a fully garbage-collected runtime, since the collector can't know an object is logically unused if something still technically points to it.
5 / 5
During a PR review, a teammate asks why the team still worries about references being held longer than necessary in a garbage-collected language, given that the runtime is supposed to reclaim unused memory automatically. What is the reasoning?
The garbage collector only reclaims memory that's genuinely unreachable from any live reference, so a forgotten reference, like an event listener nobody unsubscribed, keeps its target reachable and therefore un-reclaimable, even though the program has logically moved on and no longer needs it. This is why garbage collection eliminates dangling-pointer and double-free bugs but doesn't eliminate the discipline of releasing references you're truly done with. The tradeoff is that a garbage-collected language still requires this reference-lifecycle awareness, just shifted from manual memory management to manual reference management.