Learn the vocabulary of a long-running process's memory usage climbing without ever shrinking back.
0 / 5 completed
1 / 5
At standup, a dev mentions a long-running process whose memory usage keeps climbing over days because allocated memory is never released, even though the program no longer uses it. What is this bug called?
A memory leak is exactly a long-running process whose memory usage keeps climbing because allocated memory is never released, even though the program has logically stopped using it, whether due to a forgotten reference, an unclosed resource, or a manual allocation that's never freed. Garbage collection is the mechanism meant to prevent this in managed languages, though a leak can still occur if a reference is unintentionally kept alive. This slow, steady climb in memory usage is the classic symptom that distinguishes a leak from a one-time spike.
2 / 5
During a design review, the team wants automated tooling to periodically snapshot the process's heap and flag object counts that keep growing across snapshots without ever shrinking back down. Which capability supports this?
Heap-snapshot diffing, or a dedicated memory profiler, identifies exactly which object type keeps accumulating without bound by comparing counts across multiple snapshots over time, pinpointing the leak's source far faster than manual inspection. A single one-time snapshot only shows a moment in time and can't reveal a growth trend on its own. This diffing technique is the standard way to actually locate a leak's root cause once memory growth has already been observed in production.
3 / 5
In a code review, a dev notices a database connection or a file handle is opened at the start of a function but never explicitly closed on an error branch that returns early. What does this represent?
This is a resource leak, a close cousin of a memory leak, where an underlying system resource like a database connection or a file handle is never explicitly released, even if the wrapping object in memory is eventually garbage collected, since the operating system or database still considers that resource held until it's explicitly closed. A cache eviction policy is an unrelated concept about discarding cached data. This is exactly why resource cleanup typically needs an explicit, guaranteed release, such as a try/finally block, rather than relying on garbage collection's own timing.
4 / 5
An incident report shows a server had to be restarted every few days because its memory usage grew steadily until the process was killed by the operating system, and a heap profiler eventually traced the growth to a cache that was never evicting old entries. What practice would prevent this?
Adding an eviction policy, or a maximum size bound, ensures the cache actually releases old entries instead of retaining every one it's ever stored, which is precisely what let memory grow until the process was killed in this incident. Continuing to let the cache grow with no bound at all is exactly the unbounded-accumulation pattern a memory leak depends on. This bounded, evicting cache design is a standard requirement for any in-memory cache running inside a long-lived process.
5 / 5
During a PR review, a teammate asks why the team invests in heap-snapshot diffing and profiling tools instead of just restarting the service periodically to keep memory usage under control. What is the reasoning?
Periodic restarts mask the symptom of a leak without touching its underlying cause, so the same growth keeps recurring, and as the leak's rate or the service's traffic increases, the safe restart interval keeps having to shrink until it becomes operationally painful. Profiling tools instead trace the growth back to its actual source, like an unbounded cache or a forgotten listener, so the leak can be fixed once and doesn't keep coming back. The tradeoff is the upfront investigative effort of profiling versus the ongoing operational cost of babysitting a restart schedule indefinitely.