A: Allocation is a pointer bump in a contiguous nursery — the runtime increments a pointer and returns the previous value, which is a handful of instructions. Collection cost, by contrast, is proportional to the objects that survive, because the collector traces reachable objects from the roots and copies or compacts them; dead objects cost nothing, they are simply not visited. That inversion is why generating large volumes of short-lived garbage is nearly free while retaining a moderate number of medium-lived objects is expensive, and why the right optimisation target is usually survival rate rather than allocation count.

A: It is when objects live long enough to survive gen-0 and gen-1 collections and be promoted into gen 2, but not long enough to be genuinely permanent — objects cached for a few seconds, sitting in a queue, or captured by a medium-lived task. It is the worst case because gen-0 collections are cheap precisely when almost nothing survives, while gen-2 collections are expensive and rare; promoting a steady stream of objects into gen 2 means paying the promotion cost and forcing frequent expensive collections to clean them up again. The design implication is that objects should either die immediately or live for the process lifetime, and the shapes to avoid are short-lived caches and buffers held just past their natural scope.

A: Workstation GC uses a single heap tuned for low latency on a single-user machine, while Server GC creates a separate heap and dedicated collection thread per core, which greatly improves allocation throughput on multi-core servers at the cost of higher memory usage. ASP.NET Core enables Server GC by default. In a container it matters because the runtime sizes those per-core structures from the CPU count it can see: if the container's CPU limit is not correctly surfaced, the runtime provisions heaps for every host core, and memory usage far exceeds what the container limit allows, producing an OOM kill that looks inexplicable. Ensuring the runtime honours cgroup limits, or explicitly configuring the GC mode and heap count, is a standard production step.

A: The collector frees only unreachable objects, so a leak is always unintended reachability — something is still holding a reference. The usual causes are a static collection or in-process cache that only grows because it has no eviction policy, event handlers that are never unsubscribed so the publisher keeps every subscriber alive, lambdas or timer callbacks capturing this and thereby the whole object graph behind it, and undisposed objects wrapping unmanaged resources such as sockets or file handles. Diagnosis is a heap dump at two points in time, comparing what grew, and then inspecting the retention path rather than the object type — because the leaking object is rarely the interesting part; whatever is holding it is.

A: It holds allocations of 85,000 bytes or more, which in practice means large arrays, big strings, and buffers. It creates two problems: it is only collected as part of a gen-2 collection, so large temporary buffers keep memory occupied far longer than their logical lifetime, and it is not compacted by default, so a pattern of allocating and releasing differently-sized large arrays fragments it until an allocation fails despite substantial free memory. The mitigations are to pre-size collections so a single allocation replaces a doubling sequence, to rent reusable buffers from ArrayPool<T>.Shared rather than allocating fresh ones, and to chunk data so no individual array crosses the threshold.

A: It is good for objects that are genuinely expensive to create or that are large enough to hit the LOH — big byte buffers, database connections, and similar. ArrayPool<T>.Shared is the standard vehicle, with the rented array returned in a finally block. It backfires for cheap short-lived objects, because it converts free gen-0 garbage into long-lived pooled objects that survive into gen 2, which is precisely the mid-life-crisis pattern you were trying to avoid — you pay more in collection cost than you save in allocation. Pooling also introduces real correctness hazards: a rented buffer contains the previous tenant's data unless cleared, and forgetting to return it is a leak with none of the GC's protection.

A: Replace substring extraction with ReadOnlySpan<char> slicing, which creates a view over the existing characters rather than allocating a new string per field — often taking the allocation count in the loop to zero. Use the span-based TryParse overloads so numbers are parsed directly from the span without an intermediate string. Build output with a StringBuilder or by writing into a pooled buffer rather than concatenating. And where a large working buffer is needed, rent it from ArrayPool<T>.Shared instead of allocating one per call. The constraint to remember is that Span<T> is a ref struct confined to the stack, so it cannot be stored in a field, captured in a lambda, or held across an await; Memory<T> covers the async cases.

A: I look at which generation is collecting, because the answer points in completely different directions. A high gen-0 rate with a low promotion rate means a high allocation volume on a hot path, and the fix is to reduce allocations there — spans, pooled buffers, pre-sized collections, avoiding closures and boxing in the loop. A high gen-2 rate means objects are surviving into the old generation, which points at a growing cache, a leak, or the mid-life-crisis pattern, and the fix is a heap dump to find what is being retained and by what. I would also check whether the LOH is involved, since large-array churn drives gen-2 collections directly, and whether Server GC is configured appropriately for the container's actual CPU and memory limits.