An ExecutorService that executes each submitted task using
one of possibly several pooled threads, normally configured
using Executors factory methods.
Thread pools address two different problems: they usually
provide improved performance when executing large numbers of
asynchronous tasks, due to reduced per-task invocation overhead,
and they provide a means of bounding and managing the resources,
including threads, consumed when executing a collection of tasks.
Each ThreadPoolExecutor also maintains some basic
statistics, such as the number of completed tasks.
To be useful across a wide range of contexts, this class
provides many adjustable parameters and extensibility
hooks. However, programmers are urged to use the more convenient
Executors factory methods Executors.newCachedThreadPool (unbounded thread pool, with
automatic thread reclamation), Executors.newFixedThreadPool
(fixed size thread pool) and Executors.newSingleThreadExecutor (single background thread), that
preconfigure settings for the most common usage
scenarios. Otherwise, use the following guide when manually
configuring and tuning this class:
ThreadPoolExecutor will automatically adjust the
pool size (see getPoolSize)
according to the bounds set by
corePoolSize (see getCorePoolSize) and
maximumPoolSize (see getMaximumPoolSize).
When a new task is submitted in method execute(Runnable),
and fewer than corePoolSize threads are running, a new thread is
created to handle the request, even if other worker threads are
idle. If there are more than corePoolSize but less than
maximumPoolSize threads running, a new thread will be created only
if the queue is full. By setting corePoolSize and maximumPoolSize
the same, you create a fixed-size thread pool. By setting
maximumPoolSize to an essentially unbounded value such as
Integer.MAX_VALUE, you allow the pool to accommodate an arbitrary
number of concurrent tasks. Most typically, core and maximum pool
sizes are set only upon construction, but they may also be changed
dynamically using setCorePoolSize and setMaximumPoolSize. prestartCoreThread or prestartAllCoreThreads. You probably want to prestart threads if
you construct the pool with a non-empty queue. ThreadFactory. If not
otherwise specified, a Executors.defaultThreadFactory is
used, that creates threads to all be in the same ThreadGroup and with the same NORM_PRIORITY priority and
non-daemon status. By supplying a different ThreadFactory, you can
alter the thread's name, thread group, priority, daemon status,
etc. If a ThreadFactory fails to create a thread when asked
by returning null from newThread, the executor will
continue, but might not be able to execute any tasks. Threads
should possess the "modifyThread" RuntimePermission. If
worker threads or other threads using the pool do not possess this
permission, service may be degraded: configuration changes may not
take effect in a timely manner, and a shutdown pool may remain in a
state in which termination is possible but not completed.getKeepAliveTime(TimeUnit)).
This provides a means of reducing resource consumption when the
pool is not being actively used. If the pool becomes more active
later, new threads will be constructed. This parameter can also be
changed dynamically using method setKeepAliveTime(long,
TimeUnit). Using a value of Long.MAX_VALUE TimeUnit.NANOSECONDS effectively disables idle threads from ever
terminating prior to shut down. By default, the keep-alive policy
applies only when there are more than corePoolSize threads. But
method allowCoreThreadTimeOut(boolean) can be used to
apply this time-out policy to core threads as well, so long as the
keepAliveTime value is non-zero. BlockingQueue may be used to transfer and hold
submitted tasks. The use of this queue interacts with pool sizing:
SynchronousQueue that hands off tasks to threads
without otherwise holding them. Here, an attempt to queue a task
will fail if no threads are immediately available to run it, so a
new thread will be constructed. This policy avoids lockups when
handling sets of requests that might have internal dependencies.
Direct handoffs generally require unbounded maximumPoolSizes to
avoid rejection of new submitted tasks. This in turn admits the
possibility of unbounded thread growth when commands continue to
arrive on average faster than they can be processed. LinkedBlockingQueue without a predefined
capacity) will cause new tasks to wait in the queue when all
corePoolSize threads are busy. Thus, no more than corePoolSize
threads will ever be created. (And the value of the maximumPoolSize
therefore doesn't have any effect.) This may be appropriate when
each task is completely independent of others, so tasks cannot
affect each others execution; for example, in a web page server.
While this style of queuing can be useful in smoothing out
transient bursts of requests, it admits the possibility of
unbounded work queue growth when commands continue to arrive on
average faster than they can be processed. ArrayBlockingQueue) helps prevent resource exhaustion when
used with finite maximumPoolSizes, but can be more difficult to
tune and control. Queue sizes and maximum pool sizes may be traded
off for each other: Using large queues and small pools minimizes
CPU usage, OS resources, and context-switching overhead, but can
lead to artificially low throughput. If tasks frequently block (for
example if they are I/O bound), a system may be able to schedule
time for more threads than you otherwise allow. Use of small queues
generally requires larger pool sizes, which keeps CPUs busier but
may encounter unacceptable scheduling overhead, which also
decreases throughput. execute(Runnable) will be
rejected when the Executor has been shut down, and also when
the Executor uses finite bounds for both maximum threads and work queue
capacity, and is saturated. In either case, the execute method
invokes the RejectedExecutionHandler.rejectedExecution(Runnable, ThreadPoolExecutor)
method of its RejectedExecutionHandler. Four predefined handler
policies are provided:
ThreadPoolExecutor.AbortPolicy, the
handler throws a runtime RejectedExecutionException upon
rejection. ThreadPoolExecutor.CallerRunsPolicy, the thread
that invokes execute itself runs the task. This provides a
simple feedback control mechanism that will slow down the rate that
new tasks are submitted. ThreadPoolExecutor.DiscardPolicy, a task that
cannot be executed is simply dropped. ThreadPoolExecutor.DiscardOldestPolicy, if the
executor is not shut down, the task at the head of the work queue
is dropped, and then execution is retried (which can fail again,
causing this to be repeated.) RejectedExecutionHandler classes. Doing so requires some care
especially when policies are designed to work only under particular
capacity or queuing policies. protected overridable
beforeExecute(Thread, Runnable) and
afterExecute(Runnable, Throwable) methods that are called
before and after execution of each task. These can be used to
manipulate the execution environment; for example, reinitializing
ThreadLocals, gathering statistics, or adding log entries.
Additionally, method terminated can be overridden to perform
any special processing that needs to be done once the Executor has
fully terminated.
If hook or callback methods throw exceptions, internal worker threads may in turn fail and abruptly terminate.
getQueue() allows access to the work queue
for purposes of monitoring and debugging. Use of this method for
any other purpose is strongly discouraged. Two supplied methods,
remove(Runnable) and purge are available to
assist in storage reclamation when large numbers of queued tasks
become cancelled. shutdown automatically. If
you would like to ensure that unreferenced pools are reclaimed even
if users forget to call shutdown, then you must arrange
that unused threads eventually die, by setting appropriate
keep-alive times, using a lower bound of zero core threads and/or
setting allowCoreThreadTimeOut(boolean). Extension example. Most extensions of this class override one or more of the protected hook methods. For example, here is a subclass that adds a simple pause/resume feature:
class PausableThreadPoolExecutor extends ThreadPoolExecutor {
private boolean isPaused;
private ReentrantLock pauseLock = new ReentrantLock();
private Condition unpaused = pauseLock.newCondition();
public PausableThreadPoolExecutor(...) { super(...);
protected void beforeExecute(Thread t, Runnable r) {
super.beforeExecute(t, r);
pauseLock.lock();
try {
while (isPaused) unpaused.await();
} catch (InterruptedException ie) {
t.interrupt();
} finally {
pauseLock.unlock();
}
}
public void pause() {
pauseLock.lock();
try {
isPaused = true;
} finally {
pauseLock.unlock();
}
}
public void resume() {
pauseLock.lock();
try {
isPaused = false;
unpaused.signalAll();
} finally {
pauseLock.unlock();
}
}
}}
extends