Thread Pooling in Java 5

Thread Pooling in Java 5 is configured using one of the implementations of the executor interface.
One implementation is ThreadPoolExecutor. This implementation, as the name, suggests is configurable with the no of threads in the pool, the maximum pool size, a rejection handler, a thread factory, a work queue.

Executor <---------- ExecutorService <-------- AbstractExecutorService <----------- ThreadPoolExecutor <---------- ScheduledThreadPoolExecutor (This is the depiction of the hierarchy => Executor is extended by the ExecutorService interface which is realized by the AbstractExecutorService class and so on)

The significance of these configurable parameters is listed below barring the self explanatory parameters:

1. Rejection Handler / Saturation Policies: This is an implementation that determines the policy to be used in cases when a task is to be rejected. The rejection could be because of many reasons: the work queue is filled up, the executor is shutting down etc. There are predefined policies as well that are detailed in the JavaDocs.
2. Thread Factory: An implementation of this will be used by the executor (ThreadPoolExecutor in this case) to create the pool thread. This is very useful since a customized thread factory implementation can be setup to perform a variety of customizations. Such as: specifying an UncaughtExceptionHandler on a per thread basis.
3. Work Queue: This is where the tasks that are to be executed are held at. One could configure the work queue to be of a certain size. The pool threads will pop off this work queue and execute the tasks based on a certain policy that in turn is based on the BlockingQueue implementation. For instance: if the work queue is a PriorityQueue then tasks will be popped off based on priority.
   

A ScheheduledThreadPoolExecutor can additionally be setup to execute tasks periodically. A task can be scheduled to execute after a given delay and at a specified interval thereafter. If a task takes longer than the interval specified to execute then another thread is spawned or reused from the pool to execute the task. This is different from a Timer in terms of the task always is executed after the interval even if the preceding task is still running.

Difference between executor obtained from Executors and directly instantiating the ThreadPoolExecutor or ScheduledThreadPoolExecutor

The distinguishing facet is that the Executor obtained from the new****Thread*** methods in Executors is preconfigured and cannot be reconfigured while it is running. Of course one can cast it to ThreadPoolExecutor (or any other implementation) and then invoke it's configuration API but it is discouraged since that would require coupling the caller and the callee.
An Executor so obtained is preconfigured in terms of:
. Saturation Policies
. Thread Factory
. Work Queue

In order to customize, one would need to instantiate the appropriate Executor such as ThreadPoolExecutor or ScheduledThreadPoolExecutor.