MemoryPool<T> in .NET: Pooling Memory Beyond Arrays

Same pooling idea as ArrayPool<T> — reshaped for a world where the memory isn't always a plain array.

The previous lesson solved a real problem: stop reallocating the same buffer over and over, rent it from a shared pool instead. But it solved it specifically for T[] — plain arrays. Recall two lessons back: Memory<T> exists precisely because not every scenario that needs a memory view can be pinned to a plain array — it might wrap native or unmanaged memory instead, memory an ordinary T[] can never represent. If your code is already working in terms of Memory<T> — because it's async, or because it's designed against an IMemoryOwner<T>-based API — ArrayPool<T>'s array-shaped contract doesn't quite fit.

In this lesson, you'll meet MemoryPool<T> — the Memory<T>-flavored counterpart to ArrayPool<T>, and you'll see how its IMemoryOwner<T> return value gives you automatic, RAII-style cleanup instead of a manual Return call.

What Is It?

The Simple Explanation

MemoryPool<T> is ArrayPool<T>'s sibling: same underlying idea — borrow reusable memory instead of allocating fresh each time — but it hands you back a Memory<T>-compatible object, wrapped in something that knows how to clean up after itself automatically.

The Technical Definition

MemoryPool<T> (in System.Buffers) is a resource pool for Memory<T>-based memory. MemoryPool<T>.Shared gives you the default, process-wide instance. Its core operation:

• Rent(int minBufferSize = -1) — returns an IMemoryOwner<T>, an object that owns a rented block of memory and exposes it through a .Memory property.

There's no separate Return method to call. Instead, IMemoryOwner<T> implements IDisposable — disposing it is what returns the underlying memory to the pool. That's the whole design difference from ArrayPool<T> in one sentence: ownership and cleanup are modeled explicitly, through the same IDisposable/using pattern you already use for files, connections, and every other disposable resource in .NET.

Why Does It Exist?

The Problem — Memory<T> doesn't have to be an array

Two lessons back, Memory<T> was introduced as the heap-friendly, storable counterpart to Span<T> — commonly backed by an array, but not required to be. It can also wrap native or unmanaged memory, memory obtained from platform interop, or other custom memory sources that were never a T[] to begin with. ArrayPool<T> is built specifically around lending out and reclaiming T[] instances — it has no vocabulary for pooling memory that isn't shaped like a plain array in the first place.

The Solution

MemoryPool<T> generalizes the pooling idea to whatever Memory<T> can represent, not just arrays. Its default (MemoryPool<T>.Shared) is commonly array-backed under the hood in the mainstream .NET implementation, but the abstraction itself — and any custom MemoryPool<T> implementation — isn't limited to that. Pairing it with IMemoryOwner<T> also solves a second, smaller problem: manual Return calls are easy to forget (as the previous lesson's Common Mistakes covered) — modeling ownership as a disposable object lets you lean on using to make returning automatic and much harder to skip.

Big Picture

How It Works

using IMemoryOwner<byte> owner = MemoryPool<byte>.Shared.Rent(8192);

Memory<byte> buffer = owner.Memory;
int bytesRead = await upload.ReadAsync(buffer[..8192]); // Memory<T> survives the await, as covered previously

Span<byte> span = buffer.Span[..bytesRead]; // convert to Span<T> for the fast, synchronous part
ProcessChunk(span);

Simple Example — the same upload loop, rewritten with MemoryPool<T>

async Task ProcessUploadAsync(Stream upload)
{
    using IMemoryOwner<byte> owner = MemoryPool<byte>.Shared.Rent(8192);
    Memory<byte> buffer = owner.Memory;

    while (true)
    {
        int bytesRead = await upload.ReadAsync(buffer[..8192]);
        if (bytesRead == 0) break;

        ProcessChunk(buffer.Span[..bytesRead]);
    }
    // owner.Dispose() runs automatically here, returning the memory to the pool —
    // no explicit Return call, no try/finally required
}

Compare this to the previous lesson's ArrayPool<T> version: the logic is identical — rent once, reuse across the loop, clean up when done — but there's no manual Return call and no explicit try/finally. The using declaration on owner handles both jobs at once, exactly the way it already handles closing a file or a database connection.

Real-World Example

MemoryPool<T> shows up specifically where code is already committed to the Memory<T>/IMemoryOwner<T> shape — often because it's crossing async boundaries or interoperating with lower-level, pipeline-style APIs:

• Custom implementations of streaming, pipeline-based APIs (in the spirit of System.IO.Pipelines) that are built around Memory<T> end-to-end rather than raw arrays.
• Libraries exposing buffers across an async boundary where the caller shouldn't need to know or care whether the underlying memory happens to be array-backed or something else.
• Any code where you want the compiler-enforced, using-driven guarantee that a rented buffer is returned, rather than relying on every caller to remember a manual Return.

For the far more common case — a plain, synchronous or simply-async buffer that's naturally a byte[] — ArrayPool<T> remains the simpler, more directly-applicable tool, which is exactly why it's typically reached for first.

Analogy

Under the Hood

Common Confusion

1. "MemoryPool<T> is strictly better than ArrayPool<T>, so I should always use it"

Not quite — they serve different shapes of code. If you genuinely need a plain T[] (many APIs still expect exactly that), ArrayPool<T> gives you one directly, with no extra indirection through Memory<T>/.Span. Reach for MemoryPool<T> specifically when your code is already working in Memory<T> terms — not as a blanket upgrade.

2. "Disposing the IMemoryOwner<T> clears the memory's contents, like ArrayPool<T>'s clearArray option"

Disposal returns the memory to the pool — it doesn't, by itself, guarantee the contents are zeroed for the next renter, mirroring ArrayPool<T>'s own default (non-clearing) behavior. If leftover contents matter for your scenario, that's a concern to handle deliberately, the same way it was in the previous lesson.

3. "I need MemoryPool<T> any time I'm working with Memory<T>"

Not at all — plenty of code creates a Memory<T> from an ordinary, non-pooled array (array.AsMemory()) with no pooling involved whatsoever. MemoryPool<T> is specifically for when you want the reuse/pooling benefit and you're working in Memory<T> terms — the two ideas (using Memory<T>, and pooling) are independent of each other.

Common Mistakes

Mistake 1 — Using owner.Memory after disposing the owner

Holding onto owner.Memory (or a Span<T> derived from it) in a variable that outlives the using block that owns it.

Memory<byte> leaked;
using (IMemoryOwner<byte> owner = MemoryPool<byte>.Shared.Rent(1024))
{
    leaked = owner.Memory; //  still valid as a reference, but the pool now owns this memory again
} // owner disposed here — 'leaked' may be reused/overwritten by an unrelated future Rent

Never let a Memory<T> obtained from an IMemoryOwner<T> escape the scope that owns it — use it only while the owner itself is still alive and undisposed.

Mistake 2 — Reaching for MemoryPool<T> when a plain array would do

Adding MemoryPool<T> and its extra .Memory/.Span indirection to code that just needs a straightforward, synchronous byte[] buffer.

Default to ArrayPool<T> for plain array needs — it's simpler and gives you the array directly. Reach for MemoryPool<T> when the surrounding code is genuinely built around Memory<T>.

Mistake 3 — Forgetting the using declaration entirely

Calling MemoryPool<byte>.Shared.Rent(...) without assigning it to a using-declared variable — the RAII benefit only exists if you actually use the pattern.

Always pair Rent with using (either a using declaration or a using block) — that's the entire mechanism that makes automatic return work.

When Should I Use It?

Mental Model

Key Takeaway

Check Your Understanding

You've seen how MemoryPool<T> relates to, and differs from, ArrayPool<T>. Let's confirm the distinction is clear.

You now have both pooling tools in your kit, and know exactly when each one fits. Next: a precise, deep look at ref, in, and out — the parameter-passing modifiers that make some of this module's performance techniques possible in the first place.