Learn the vocabulary of freeing an object the instant its active reference count reaches zero.
0 / 5 completed
1 / 5
At standup, a dev mentions a memory-management scheme where each object tracks how many active references point to it, and the object is freed the instant that count drops to zero. What is this technique called?
Reference counting has each object track how many active references currently point to it, incrementing that count whenever a new reference is created and decrementing it whenever one goes away, freeing the object immediately the instant the count reaches zero. A tracing garbage collector instead periodically scans the whole object graph from a set of roots to determine what's still reachable, rather than reacting instantly to each individual reference change. This immediate-on-zero freeing is exactly what makes reference counting predictable in when memory gets reclaimed, at the cost of the bookkeeping overhead of updating a count on every single reference change.
2 / 5
During a design review, the team notices two objects hold references to each other and nothing else outside that pair ever references either one. Which problem does this create for plain reference counting?
This creates a reference cycle that keeps both objects' counts above zero forever, since each object in the pair is still being referenced by the other one, so neither object's count ever drops to zero even though nothing outside that pair can actually reach either one anymore, leaving both permanently un-freed. Two unrelated objects with no references to each other have no such problem, since each one's count correctly reflects whether anything can still reach it. This cycle problem is exactly the well-known limitation of plain reference counting, which is why many reference-counted systems pair it with a separate cycle-detecting collector to catch exactly this case.
3 / 5
In a code review, a dev notices a parent object holds a strong reference to its child, and the child also holds a strong reference straight back to its parent, with nothing outside that parent-child pair ever referencing either one. What does this represent?
This is a reference cycle that will leak under plain reference counting, since the parent's strong reference keeps the child's count above zero and the child's strong reference back keeps the parent's count above zero, so neither one is ever freed even after nothing outside that pair can reach either of them anymore. A cache eviction policy is an unrelated concept about discarded cache entries. This exact parent-child-back-reference shape is one of the most common real-world sources of a reference cycle, which is why many reference-counted systems introduce a weak reference specifically for a child's pointer back to its parent.
4 / 5
An incident report shows a long-running application's memory usage grew steadily because a parent-child object pair, each holding a strong reference to the other, was never actually freed after both became unreachable from anywhere else in the program, since plain reference counting couldn't detect the cycle between them. What practice would prevent this?
Making the child's reference back to its parent a weak reference, one that doesn't count toward the parent's reference count, breaks the cycle entirely, so once nothing external references either object, the parent's count can correctly drop to zero and free both, which is exactly the fix for the steady memory growth described in this incident. Continuing to let the child hold a strong reference back to its parent is exactly what kept both objects' counts above zero forever, even once they were truly unreachable from the rest of the program. This weak-reference-for-back-pointer pattern is the standard fix for exactly this common parent-child cycle shape.
5 / 5
During a PR review, a teammate asks why the team deliberately makes a child's reference back to its parent weak instead of just leaving both directions as strong references for simplicity. What is the reasoning?
Two strong references pointing at each other, one from parent to child and one from child back to parent, form exactly the kind of cycle that keeps both objects' reference counts above zero forever under plain reference counting, since each object is still technically referenced by the other, even long after nothing outside that pair can actually reach either one. Making the back-reference weak removes it from the reference count entirely, so once the parent's own external references disappear, its count correctly drops to zero and both objects can be freed together. The tradeoff is that any code following a weak reference has to first check whether the object it points to is still actually alive, since a weak reference alone doesn't keep its target from being freed.