What are closures in C#? Explain how captured variables are hoisted into a compiler-generated class, why capture is by variable rather than by value, the for-loop versus foreach capture difference, closures in async code and timers, the allocation and memory-leak risks, and how static lambdas help.

How I would answer this in an interview

A closure is a lambda (or local function) plus the variables it captures from its enclosing scope. In C#, the compiler implements captures by hoisting those variables into a compiler-generated class, so the lambda and the enclosing method share the same variable, not a copy. That explains the classic loop bugs, async/timer surprises, hidden allocations and memory leaks — and why static lambdas exist.

1. Hoisting into a display class

public Func<Order, bool> IsOverLimit(decimal limit)
{
    var margin = 0.05m;
    return o => o.Total > limit * (1 + margin);
}

compiles to roughly:

sealed class <>c__DisplayClass0_0 { public decimal limit; public decimal margin;
    internal bool <IsOverLimit>b__0(Order o) => o.Total > limit * (1 + margin); }

public Func<Order, bool> IsOverLimit(decimal limit)
{
    var closure = new <>c__DisplayClass0_0 { limit = limit, margin = 0.05m };   // locals now live here
    return closure.<IsOverLimit>b__0;                                            // delegate bound to the closure
}

The captured locals stop being stack variables: every read/write in the method goes through the closure object, which lives as long as any delegate referencing it.

2. Capture by variable, not by value

var threshold = 100m;
var isBig = (Order o) => o.Total > threshold;
threshold = 1000m;
isBig(new Order { Total = 500m });   // false - lambda sees the CURRENT value (1000)

The lambda reads the variable when it runs, not when it was created. If you need a snapshot, copy into a new local before capturing.

3. for vs foreach capture

var actions = new List<Action>();
for (int i = 0; i < 3; i++) actions.Add(() => Console.Write(i));   // prints 333
foreach (var n in new[] { 0, 1, 2 }) actions.Add(() => Console.Write(n));  // prints 012

• A for loop has one variable i for the whole loop, incremented each iteration — all lambdas share it.
• Since C# 5, foreach declares a fresh variable per iteration (a breaking change made because the old behaviour caused so many bugs).
• Fix for for: int copy = i; actions.Add(() => Console.Write(copy));.

4. Closures in async code and timers

for (int i = 0; i < files.Length; i++)
    tasks.Add(Task.Run(() => Process(files[i])));   // i may be files.Length by the time it runs -> IndexOutOfRangeException

Delayed execution (tasks, timers, callbacks, event handlers, IObservable) makes capture-by-variable bugs worse: the variable has moved on by the time the lambda runs. Timers and long-lived callbacks also keep captured objects alive:

_timer = new Timer(_ => Refresh(), null, 0, 1000);   // captures 'this' - the timer keeps this object alive

5. Allocation and memory-leak risks

• Allocations: each entry into a scope with captured variables allocates a closure; each lambda evaluation allocates a delegate. In hot paths (per request, per item) this adds GC pressure.
• Shared closure: all lambdas in the same scope share one display class. If one lambda captures a large object (e.g. a 50 MB buffer) and another small lambda is stored long-term, the big object stays alive too.
• Leaks: closures stored in long-lived places (static events, caches, singleton callbacks, timers) keep captured objects — including this, DbContext, HttpContext — alive indefinitely.
• Captured HttpContext/scoped services in background tasks: the request ends and the captured objects are disposed or reused → ObjectDisposedException or data from another request.

6. How static lambdas help

cache.GetOrAdd(key, static (k, loader) => loader.Load(k), _loader);   // no capture
string.Create(len, state, static (span, s) => ...);

static lambdas (C# 9) can't capture anything; the compiler errors if they try. Combined with state-passing overloads (GetOrAdd(key, factory, arg), ThreadPool.QueueUserWorkItem(callback, state, preferLocal), Task.Factory.StartNew(action, state)), they eliminate closure allocations and accidental captures. Non-capturing lambdas are also cached as singleton delegates by the compiler.

7. A production example

A request handler started a background task with Task.Run(() => _audit.WriteAsync(HttpContext.User.Identity!.Name, order)). Under load, audit entries occasionally recorded the wrong user or threw ObjectDisposedException — the closure captured this (the controller) and its HttpContext, which ASP.NET Core recycles after the request ends. We captured plain values first (var user = User.Identity!.Name; var orderId = order.Id;) and moved the work to a background queue with a static lambda, fixing both the data corruption and the allocation churn.