GC cost, allocation rate and memory budgets

A high allocation rate with a small live heap suggests churn: many objects become garbage quickly. A growing live heap suggests retained data or a growing workload. Capture representative profiles before changing code; removing one temporary allocation is not helpful if a cache retains gigabytes indefinitely.

GOGC influences the heap-growth target and therefore the tradeoff between collection frequency and memory. GOMEMLIMIT is a soft runtime memory limit, not an operating-system hard cap. Native allocations and other process memory can require additional budget. Leave measured headroom under the container limit rather than making the two numbers equal.

Avoid retaining whole request graphs in queues, bound cache entries, and reuse buffers only with clear ownership and size limits. Increasing a memory allowance may reduce collection frequency but raises memory use; forcing very frequent GC can waste CPU. A pool is an optimization with lifecycle constraints, not a guarantee that objects will stay cached or that memory use is bounded.