Fragmentation happens when you allocate and free blocks of varying sizes: freeing a small block between two live ones leaves a small hole that can't satisfy a larger request, so over time the heap becomes a patchwork of unusable gaps and a large allocation fails even though the total free memory is sufficient. A pool allocator carves memory into uniform, fixed-size blocks. Every allocation takes exactly one block and every free returns exactly one block, so any freed block can satisfy any future request, there's no notion of "a hole too small," because all holes are the same block size. Allocation and free are O(1) (pop/push a free list of blocks), and total memory is hard-bounded at the block count. The tradeoff is the uniform size: small objects waste the remainder of their block, and objects larger than a block don't fit, so you size the block deliberately or run several pools, one per size class.
Data Structures & Algorithms · Interview question
Why is a pool allocator immune to fragmentation when general malloc isn't?
A strong answer
What a weak answer sounds like
You know the answer. Do you know what gets you dinged?
Pro breaks down the answer most candidates actually give to this question — and the specific reason an interviewer marks it down. It’s the difference between sounding correct and sounding senior, on all 472 questions.
From the lesson
Static vs Dynamic Allocation
How to give data structures memory on a constrained device: static arrays, fixed-block pools, and arena allocators, the O(1), fragmentation-free alternatives to general malloc.