There are several textbooks and Internet articles that dwell on theperformance and scalability benefits of using a thread pool versus creatingnew threads in a multithreaded Java application.
While some of them overstate the benefits, most fail to emphasize someof the caveats of Java thread pooling. Due to space contraints, this articleprovides only a brief summary of the benefits and emphasizes the drawbacks.A list of references that covers the benefits in more detail is provided atthe end.
What Is Thread Pooling?
Thread pooling refers to a technique where a pool of worker threads iscreated and managed by the application. When a new job arrives, instead ofcreating a new thread to service it, it's queued by the thread-pool managerand dispatched later to one of the available worker threads. The thread-poolmanager manages the number of active worker threads based on availableresources as well as load considerations, adding new threads to the pool orfreeing some worker threads in response to the number of outstandingrequests. The primary goals of thread pooling are managing the number ofactive threads in the system and reducing the overhead of creating newthreads by reusing threads from a pool.
Why Pool Threads?
The primary argument in favor of managing the number of active threadsin the system is: threads have a memory overhead since each one needs acertain amount of memory for its stack. Threads also add schedulingoverhead, since the scheduler's work increases as the number of threadsincreases. Depending on the implementation of the Java Virtual Machine, eachJava thread on certain operating systems may correspond to an OS thread,making Java threads extremely heavyweight, and may limit the total number ofactive threads that the JVM is allowed to create.
To be clear, I'm not saying you don't need to manage the number ofactive threads in a system. After all, the benefits of multithreading dohave diminishing returns once the number of threads contending for theavailable CPUs increases. If a server can process only about 1,000simultaneous requests, it doesn't help to dispatch each incoming request asit's made. Often the requests must be queued and processed at a controlledrate to maintain the number of active requests below the server threshold. Acommon mistake, however, is to assume that dispatching queued requestsautomatically calls for the reuse of threads from a thread pool. Dispatchinga request to a new thread and letting the thread die once the request isserviced achieves the same effect on managing the number of active threadsin the system.
Thread creation also has an overhead that can be higher in many casesthan the overhead of managing a thread pool. While the argument stillapplies, the relative performance impact has changed significantly over theyears. The newer JVM implementations are optimized for creating threads;most use a combination of user-level threads (known as green threads) aswell as system-level threads (or OS threads) to make creating threads muchless expensive than in earlier implementations.
