← Concepts

阅读中文版本

Allocation Pressure

Allocation pressure is the rate of memory allocation driving collector frequency and pause distribution — the hidden latency input that GC tuning only treats downstream.

performance

Definition

Allocation pressure measures bytes allocated per second and per request. High pressure fills young generations faster, triggering more frequent collections and, when survivors overflow, promotion storms into old space. Latency impact follows allocation rate more than heap size: the collector runs because the application feeds it.

Context and scope

Profiled with allocation samplers in JVM, Go, and V8. Reduced via escape analysis friendliness, buffer reuse, primitive collections, and fewer per-request wrappers.

Common misconceptions

  • GC pauses are a collector problem — pauses are the symptom; allocation rate is the input the application controls
  • A bigger heap removes pressure — it delays collections and makes each one larger; pressure measured per unit time stays the same
  • Only large objects matter — total bytes drive young collections; many small temporaries dominate the rate

Anti-patterns

  • Wrapping every scalar in DTOs and optionals per request and multiplying the rate
  • Concatenating strings in loops instead of builders, churning intermediate buffers
  • Tuning collector flags to fight a rate problem and masking the regression until the next traffic doubling

Related concepts

Authoritative source

https://go.dev/doc/faq

What it is

Every temporary object is future collector work. The allocation rate determines how often that work is scheduled. For latency-sensitive services, bytes-per-request is the leading indicator of pause behavior under load.

How it works

The young generation fills at the allocation rate; collection frequency is rate divided by space. Faster promotion — from surviving temporaries or oversized objects — shifts work into expensive old-generation cycles. Escape analysis eliminates some allocations by stack-allocating non-escaping objects; code shape — returning pointers to locals unnecessarily — defeats it.

When to reduce

When pause logs correlate with traffic, when GC CPU share exceeds a few percent, or when p99 tracks collection frequency. Attack the top allocation sites from the profiler: restructure loops, reuse buffers, replace boxed types, and trim per-request scaffolding.

Pitfalls

Optimizing allocation without profiling misfires: the hot sites are rarely where intuition points. Escape analysis is version- and shape-sensitive — an innocent refactor can silently re-heap an allocation. Reducing rate shifts the bottleneck rather than deleting it: watch for the next limiter, often serialization or syscalls.