How do MemoryPool<T> and IMemoryOwner<T> work, and when would you use them instead of ArrayPool<T>? Explain renting and disposing owners, why the buffer can be larger than requested, ownership transfer between components, how System.IO.Pipelines uses a memory pool, writing a custom pool or MemoryManager<T> for native or pinned memory, and common mistakes.

How I would answer this in an interview

MemoryPool<T> rents memory as an IMemoryOwner<T>: a disposable object that owns a block and exposes it as Memory<T>. Disposing the owner returns the memory. Compared with ArrayPool<T> (raw arrays, manual Return), it makes ownership explicit and transferable, works with Memory<T> APIs (async, pipelines), and can be backed by non-array memory (native, pinned). I'd explain renting/disposing, why the buffer can be larger, ownership transfer, how Pipelines uses pools, custom pools/MemoryManager<T>, and common mistakes.

1. Renting and disposing owners

using IMemoryOwner<byte> owner = MemoryPool<byte>.Shared.Rent(minBufferSize: 4096);
Memory<byte> memory = owner.Memory;               // may be larger than 4096
int read = await stream.ReadAsync(memory, ct);
Process(memory.Span[..read]);
// owner.Dispose() at end of scope returns the memory to the pool

• MemoryPool<byte>.Shared is backed by ArrayPool<byte>.Shared (each owner wraps a rented array).
• After Dispose(), owner.Memory must not be used — the shared implementation throws ObjectDisposedException when accessing Memory after dispose, but slices you already took are just views and won't protect you.

2. Why the buffer can be larger than requested

Rent(minBufferSize) guarantees at least that size. The underlying ArrayPool uses power-of-two buckets, so Rent(1000) typically returns 1024. Rent() with no size (-1) returns a default size (often 4 KB for the shared pool). Always track the used length and slice; never assume memory.Length == requested.

3. Ownership transfer between components

The main reason to use IMemoryOwner<T>: it makes who must dispose explicit:

public sealed record Frame(IMemoryOwner<byte> Owner, int Length) : IDisposable
{
    public ReadOnlyMemory<byte> Data => Owner.Memory[..Length];
    public void Dispose() => Owner.Dispose();
}

// Producer: rents and transfers ownership
var owner = MemoryPool<byte>.Shared.Rent(size);
int len = Fill(owner.Memory.Span);
await channel.Writer.WriteAsync(new Frame(owner, len), ct);   // producer no longer owns it

// Consumer: takes ownership and disposes
await foreach (var frame in channel.Reader.ReadAllAsync(ct))
    using (frame) await HandleAsync(frame.Data, ct);

Rules (from .NET's memory usage guidelines):

• The holder of an IMemoryOwner<T> is responsible for disposing it exactly once.
• Passing Memory<T> (not the owner) to a method lends it for the call only.
• Passing IMemoryOwner<T> transfers ownership; the sender must not use or dispose it afterwards.
• Document ownership in API names/comments (e.g. TakeOwnership).

With raw ArrayPool arrays, the same discipline relies on convention and is easier to get wrong.

4. How System.IO.Pipelines uses a memory pool

• Pipe is created with PipeOptions(pool: MemoryPool<byte>.Shared, minimumSegmentSize: 4096, ...).
• The writer calls GetMemory(sizeHint) → the pipe rents segments from the pool as needed; you write and call Advance(n) then FlushAsync().
• The reader gets a ReadOnlySequence<byte> spanning one or more segments; calling AdvanceTo(consumed, examined) lets the pipe return fully consumed segments to the pool.
• Kestrel uses a specialised pinned block memory pool (PinnedBlockMemoryPool, 4 KB blocks on the Pinned Object Heap) so socket I/O doesn't need repeated pinning.

The pipe owns all buffers; you never dispose them yourself — you only must not keep references after AdvanceTo.

5. Custom pools and MemoryManager<T> for native or pinned memory

public sealed unsafe class NativeMemoryManager : MemoryManager<byte>
{
    private byte* _ptr; private readonly int _length;
    public NativeMemoryManager(int length) { _length = length; _ptr = (byte*)NativeMemory.Alloc((nuint)length); }
    public override Span<byte> GetSpan() => new(_ptr, _length);
    public override MemoryHandle Pin(int elementIndex = 0) => new(_ptr + elementIndex);   // already fixed
    public override void Unpin() { }
    protected override void Dispose(bool disposing) { if (_ptr != null) { NativeMemory.Free(_ptr); _ptr = null; } }
}

Memory<byte> memory = new NativeMemoryManager(64 * 1024).Memory;   // Memory<T> over native memory

• MemoryManager<T> lets Memory<T> represent native, memory-mapped, pinned or GPU-mapped memory.
• A custom MemoryPool<T> can hand out IMemoryOwner<T>s backed by such managers or by POH arrays (GC.AllocateArray<byte>(n, pinned: true)), useful for long-lived native I/O where pinning cost matters.
• Custom pools should be thread-safe, bounded, and ideally detect misuse in debug builds.

6. When to use which

7. Common mistakes

• Use after dispose via previously obtained Memory<T>/Span<T> slices.
• Double dispose of owners (the shared implementation tolerates it, custom ones may not; logic is wrong either way).
• Leaking owners (never disposed) — the pool allocates new arrays; memory pressure grows.
• Assuming exact length.
• Holding pipe buffers after AdvanceTo.
• Disposing an owner you lent out while the borrower still uses it.
• Sensitive data not cleared (the shared pool doesn't clear on return).

8. A production example

A telemetry ingestion service passed ReadOnlyMemory<byte> slices of ArrayPool buffers from a socket reader to a parsing Channel, returning the arrays right after enqueuing — causing sporadic corrupted records. We switched to IMemoryOwner<byte> frames with explicit ownership transfer (consumer disposes), and later migrated the socket reading to System.IO.Pipelines with the parser working on ReadOnlySequence<byte> and copying out only the fields it kept. Corruption disappeared and throughput rose ~25% thanks to fewer copies.