阅读中文版本

Heap Profiling

Heap profiling samples or tracks allocations to show which code paths retain memory, turning a vague leak report into a specific allocation site.

Definition

Heap profiling is the measurement of memory allocation and retention, typically by sampling allocation stacks or by capturing heap snapshots, to attribute growth to code locations.

It is used to diagnose leaks, excessive allocation pressure, and garbage collection pauses in long-running processes. Compared to simpler alternatives, this concept fits best when the trade-off it represents is the one the system actually cares about.

When to use it

A common use case is applying it at the boundary where the cost of getting it wrong is highest, and the scenario usually involves a concrete guarantee the system must uphold. Unlike an ad hoc approach, it makes that guarantee explicit, reviewable, and testable.

How it works

Sampling profilers record a fraction of allocations and extrapolate, so they add low overhead but their totals are estimates rather than exact counts.

Comparing snapshots before and after a workload distinguishes memory that is retained from memory that was merely allocated transiently.

Trade-offs and alternatives

Retention matters more than allocation volume: a hot path that allocates heavily but frees promptly is a throughput concern, not a leak. The main drawback is the extra complexity it introduces, so the benefit should clearly outweigh that cost before a team adopts it.

Common misconceptions

A persistent misconception is that heap profiling requires stopping the process. Another is that a growing heap always means a leak rather than deferred collection. For example, an engineer who assumes otherwise may design around a guarantee that does not actually exist, which only becomes obvious under load or failure.

Anti-patterns to avoid

Two recurring anti-patterns are to reading allocation profiles in production without accounting for sampling bias and to treating a post-collection snapshot as the same as a live one. Both tend to surface as hard-to-debug production issues rather than obvious test failures. Related concepts include Centralised Log Aggregation, The USE Method for Resource Analysis, Symptom-Based Alerting.