Comparison
Object poolvsThread pool
Object pool
the object is not created and destroyed, it is borrowed and given back, and forgetting to give it back exhausts everything.
Keeping a set of expensive-to-create objects alive and lending them out, instead of constructing one per use. It is the right answer for things whose cost is a handshake rather than an allocation — connections, threads, large buffers — and almost always the wrong answer for plain objects in a language with a generational collector. Its two characteristic bugs are leaked handles that never return and state left over from the previous borrower.
Full entry →Thread pool
you keep a fixed set of threads and hand them tasks, instead of spawning a new thread for every request.
A bounded set of reusable workers fed from a queue. It caps concurrency, which is the point: unbounded thread creation converts a traffic spike into memory exhaustion and context-switch thrash. Sizing is workload-dependent — roughly core count for CPU-bound work, much higher for I/O-bound — and a blocking call inside a pool sized for CPU work will stall everything.
Full entry →