Think of object pool as a specific version of more general concept of resource pooling which can be applied in many different situations. * Requesting resource

Think of object pool as a specific version of more general concept of resource pooling which can be applied in many different situations. * Requesting resource X from system Y is expensive or has a high latency * you request a bunch of X in single operation and create a "pool" from it * you local code manages distribution of resource without the overhead of interactions with Y The exact details can vary depending on specific type of object and situation, but general principle is the same. What is Y, what causes overhead when requesting X from Y, and whether X is discrete object or resource that can be subdivided doesn't matter. In case of object pools in a higher level language the X might be instances of specific class, and Y the programming language runtime. But it if you go a layer deeper X might be bytes, and Y the operating system. It's not just memory. Pooling is also commonly used for threads. Where X is a thread with all the associated OS resources, and Y is the operating system. Instead of asking operating system to create a thread for each task, a process might create a pool of bunch of threads and have task queue, with threads taking task from the queue. You might think of it as just another object pooling, but if you actually tried to implement it you might find that there is as much implementation specific differences compared to plain object pooling, as differences between object pooling and and the memory pools used within a memory allocator. The name probably comes from real life manufacturing where you might have large vat or a pool with some liquid ingredient, serving as buffer closer to where it's used. Instead of requesting and transporting it in small chunks from warehouse or a supplier. This also demonstrate that resource within a pool doesn't always come in discrete chunks. Reasons for pooling can also be different. In lower languages and the memory allocator itself you might want to avoid overhead of requesting memory from operating system, in low and medium level languages you might want to avoid overhead of memory allocator (running within the same process), in higher level languages you might want to avoid the runtime overhead of creating object instance (not the cost of plain memory allocation), at even higher level when making a game in an existing engine like Unity you might be worried about overhead added by the engine. It's turtles all the way down with each layer potentially using some kind of resource pooling to avoid interacting with next layer.