ArrayPool<T> in C#: Reuse Buffers and Cut Allocations

Why allocate a fresh buffer a thousand times a second when you could borrow the same one, over and over?

Picture a request handler that processes an uploaded file in chunks:

async Task ProcessUploadAsync(Stream upload)
{
    while (true)
    {
        byte[] buffer = new byte[8192]; // a fresh 8 KB array — every single iteration
        int bytesRead = await upload.ReadAsync(buffer);
        if (bytesRead == 0) break;

        ProcessChunk(buffer.AsSpan(0, bytesRead));
        // 'buffer' becomes garbage the instant this loop iteration ends
    }
}

Every trip through that loop allocates a brand-new 8,192-byte array, uses it for a few microseconds, and then abandons it as garbage. Under light load, this is invisible. Under real, sustained load — thousands of uploads a minute, each looping hundreds of times — you're handing the GC a relentless stream of short-lived, sizable arrays to trace and reclaim, exactly the kind of hot-path allocation pressure Advanced Part I's generational GC lesson and Part IV's high-throughput async lesson both warned you to watch for.

In this lesson, you'll meet ArrayPool<T> — a shared pool of reusable arrays that lets you borrow a buffer instead of allocating one, and hand it back when you're done so the next caller can reuse the exact same memory.

What Is It?

The Simple Explanation

ArrayPool<T> is a shared "library" of pre-allocated arrays you can check out and return, instead of allocating a new array from scratch every time you need one. Borrow one when you need it; give it back when you're done; the next person who needs a similarly-sized array gets the exact same one, already sitting in memory, ready to go.

The Technical Definition

ArrayPool<T> (in System.Buffers) is a resource pool that manages pre-allocated instances of T[], organized internally into buckets of different sizes. ArrayPool<T>.Shared gives you a process-wide, thread-safe default instance, appropriate for the vast majority of use cases. Its two core operations:

• Rent(int minimumLength) — hands you an array from the pool that is at least minimumLength elements long, allocating a new one only if the pool has nothing suitable available.
• Return(T[] array, bool clearArray = false) — hands the array back to the pool so a future Rent call can reuse it.

Why Does It Exist?

The Problem

Repeatedly allocating a sizable array in a hot loop or hot request path creates real, measurable GC pressure — every allocation is memory the GC eventually has to trace and reclaim, and at high request volume, that adds up to genuine, visible overhead. It gets worse the bigger the buffer: as you learned in Advanced Part I's generational GC lesson, any single object at or above the 85,000-byte threshold is allocated directly on the Large Object Heap, bypassing Gen0/Gen1 entirely — and the LOH isn't compacted by default, so repeatedly allocating and discarding large buffers can accumulate fragmentation over time. A buffer of, say, 64 KB used for file or network I/O sits right in the range where this starts to matter.

The Solution

ArrayPool<T> breaks the allocate-use-discard cycle. Instead of a fresh array every iteration, you rent an existing one from a shared pool, use it, and return it — so the very same underlying array gets reused by the next caller, over and over, with the pool absorbing the allocation cost exactly once (or a small number of times, as the pool grows to meet demand) rather than on every single iteration.

Big Picture

How It Works

byte[] buffer = ArrayPool<byte>.Shared.Rent(8192);

int bytesRead = await upload.ReadAsync(buffer.AsMemory(0, 8192));
ProcessChunk(buffer.AsSpan(0, bytesRead)); // use only the bytes you actually asked for / received

ArrayPool<byte>.Shared.Return(buffer);

Simple Example — the correct, safe pattern

async Task ProcessUploadAsync(Stream upload)
{
    byte[] buffer = ArrayPool<byte>.Shared.Rent(8192);
    try
    {
        while (true)
        {
            // buffer.Length may be >= 8192, but we only ever ask for/use up to 8192
            int bytesRead = await upload.ReadAsync(buffer.AsMemory(0, 8192));
            if (bytesRead == 0) break;

            ProcessChunk(buffer.AsSpan(0, bytesRead)); // only the valid, just-read portion
        }
    }
    finally
    {
        ArrayPool<byte>.Shared.Return(buffer); // guaranteed to run, even if ProcessChunk throws
    }
}

What changed from the Hook example: one buffer is rented outside the loop and reused across every iteration — not reallocated each time — and it's returned exactly once, in a finally block, so it goes back to the pool no matter how the method exits, including via an exception. Note also that the code deliberately reads and processes at most 8,192 bytes at a time — the exact amount requested — rather than assuming buffer.Length tells it how much space is "really" there.

Real-World Example

ArrayPool<T> is exactly the kind of tool that matters most under sustained, high-volume load — which is exactly why it's used pervasively inside ASP.NET Core and the wider .NET framework itself, for things like buffering request/response bodies and formatting output. Application-level scenarios where it earns its keep:

• File upload/download handlers streaming data in fixed-size chunks, exactly like the running example in this lesson.
• Network protocol implementations reading and writing messages through reusable byte buffers.
• Image or data transformation pipelines that repeatedly need a scratch buffer of roughly the same size to do intermediate work in.
• Anywhere a temporary buffer is allocated, used briefly, and discarded — and that pattern repeats often enough, under real load, for the allocation churn to show up in a profiler.

Analogy

Under the Hood

ArrayPool<byte>.Shared.Return(buffer, clearArray: true);

Common Confusion

1. "Rent(8192) always gives me exactly an 8192-length array"

Not guaranteed, and as covered above, frequently untrue in practice. Rent guarantees the array is at least the length you asked for — never less, possibly more. Code that indexes up to array.Length instead of its own tracked logical length is a latent bug waiting to process garbage data from a previous use of an oversized rented array.

2. "Forgetting to Return causes a memory leak"

Not in the GC sense — the array remains a perfectly ordinary, collectible object once nothing references it. What you actually lose is the reuse benefit for that specific array; the pool simply never sees it again and may allocate a new one to compensate. It's a performance/efficiency loss, not a correctness or leak problem.

3. "clearArray should always be true, just to be safe"

For most workloads this trades away real performance for no actual benefit, since the buffer's contents get overwritten before being read anyway. Reserve clearArray: true specifically for buffers that held sensitive data and might otherwise leak leftover bytes to an unrelated future renter.

Common Mistakes

Mistake 1 — Trusting array.Length after renting

Iterating for (int i = 0; i < buffer.Length; i++) over a rented buffer, assuming it's exactly the size requested.

byte[] buffer = ArrayPool<byte>.Shared.Rent(100);
for (int i = 0; i < buffer.Length; i++) //  buffer.Length could be 128, not 100 — processes garbage bytes 100-127
    Process(buffer[i]);

Track and use your own requested/logical length explicitly, everywhere: for (int i = 0; i < 100; i++), or better, work through a properly-bounded Span<T> slice: buffer.AsSpan(0, 100).

Mistake 2 — Not returning on an exception path

Rent, then a plain sequence of statements with no try/finally — if anything throws before the Return call at the end, the array never makes it back.

Always wrap rent/use/return in a try/finally, or use a small IDisposable wrapper type around the rent/return pair so a using block guarantees it — following the same RAII discipline you already use for other disposable resources.

Mistake 3 — Returning the same array twice, or using it after returning it

Calling Return more than once on the same array, or continuing to read/write a buffer after it's already been returned — both corrupt the pool's internal bookkeeping and can lead to two unrelated parts of your code silently sharing (and stomping on) the same array.

Treat Return as transferring ownership away, exactly once, at exactly one place — typically the single finally block that also did the corresponding Rent.

When Should I Use It?

Mental Model

Key Takeaway

Check Your Understanding

You've seen how renting and returning avoids repeated allocation. Let's check the gotchas actually landed.

You can now cut real GC pressure out of hot buffer-processing paths with ArrayPool<T> — and you know exactly why array.Length can't be trusted after renting. Next: the Memory<T>-flavored version of the same idea.