Java Doc for PooledExecutor.java in  » Ajax » Laszlo-4.0.10 » EDU » oswego » cs » dl » util » concurrent » Java Source Code / Java DocumentationJava Source Code and Java Documentation

Thread pools can be useful for several, usually intertwined reasons:

• To bound resource use. A limit can be placed on the maximum number of simultaneously executing threads.
• To manage concurrency levels. A targeted number of threads can be allowed to execute simultaneously.
• To manage a set of threads performing related tasks.
• To minimize overhead, by reusing previously constructed Thread objects rather than creating new ones. (Note however that pools are hardly ever cure-alls for performance problems associated with thread construction, especially on JVMs that themselves internally pool or recycle threads.)

Queueing

By default, this pool uses queueless synchronous channels to to hand off work to threads. This is a safe, conservative policy that avoids lockups when handling sets of requests that might have internal dependencies. (In these cases, queuing one task could lock up another that would be able to continue if the queued task were to run.) If you are sure that this cannot happen, then you can instead supply a queue of some sort (for example, a BoundedBuffer or LinkedQueue) in the constructor. This will cause new commands to be queued in cases where all MaximumPoolSize threads are busy. Queues are sometimes appropriate when each task is completely independent of others, so tasks cannot affect each others execution. For example, in an http server.

When given a choice, this pool always prefers adding a new thread rather than queueing if there are currently fewer than the current getMinimumPoolSize threads running, but otherwise always prefers queuing a request rather than adding a new thread. Thus, if you use an unbounded buffer, you will never have more than getMinimumPoolSize threads running. (Since the default minimumPoolSize is one, you will probably want to explicitly setMinimumPoolSize.)

While queuing can be useful in smoothing out transient bursts of requests, especially in socket-based services, it is not very well behaved when commands continue to arrive on average faster than they can be processed. Using bounds for both the queue and the pool size, along with run-when-blocked policy is often a reasonable response to such possibilities.

Queue sizes and maximum pool sizes can often 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 artifically low throughput. Especially if tasks frequently block (for example if they are I/O bound), a JVM and underlying OS may be able to schedule time for more threads than you otherwise allow. Use of small queues or queueless handoffs generally requires larger pool sizes, which keeps CPUs busier but may encounter unacceptable scheduling overhead, which also decreases throughput.

Maximum Pool size

The maximum number of threads to use, when needed. The pool does not by default preallocate threads. Instead, a thread is created, if necessary and if there are fewer than the maximum, only when an execute request arrives. The default value is (for all practical purposes) infinite -- Integer.MAX_VALUE, so should be set in the constructor or the set method unless you are just using the pool to minimize construction overhead. Because task handoffs to idle worker threads require synchronization that in turn relies on JVM scheduling policies to ensure progress, it is possible that a new thread will be created even though an existing worker thread has just become idle but has not progressed to the point at which it can accept a new task. This phenomenon tends to occur on some JVMs when bursts of short tasks are executed.

Minimum Pool size

The minimum number of threads to use, when needed (default 1). When a new request is received, and fewer than the minimum number of threads are running, a new thread is always created to handle the request even if other worker threads are idly waiting for work. Otherwise, a new thread is created only if there are fewer than the maximum and the request cannot immediately be queued.

Preallocation

You can override lazy thread construction policies via method createThreads, which establishes a given number of warm threads. Be aware that these preallocated threads will time out and die (and later be replaced with others if needed) if not used within the keep-alive time window. If you use preallocation, you probably want to increase the keepalive time. The difference between setMinimumPoolSize and createThreads is that createThreads immediately establishes threads, while setting the minimum pool size waits until requests arrive.

Keep-alive time

If the pool maintained references to a fixed set of threads in the pool, then it would impede garbage collection of otherwise idle threads. This would defeat the resource-management aspects of pools. One solution would be to use weak references. However, this would impose costly and difficult synchronization issues. Instead, threads are simply allowed to terminate and thus be GCable if they have been idle for the given keep-alive time. The value of this parameter represents a trade-off between GCability and construction time. In most current Java VMs, thread construction and cleanup overhead is on the order of milliseconds. The default keep-alive value is one minute, which means that the time needed to construct and then GC a thread is expended at most once per minute.

To establish worker threads permanently, use a negative argument to setKeepAliveTime.

Blocked execution policy

If the maximum pool size or queue size is bounded, then it is possible for incoming execute requests to block. There are four supported policies for handling this problem, and mechanics (based on the Strategy Object pattern) to allow others in subclasses:

Run (the default)

The thread making the execute request runs the task itself. This policy helps guard against lockup.

Wait

Wait until a thread becomes available.

Abort

Throw a RuntimeException

Discard

Throw away the current request and return.

DiscardOldest

Throw away the oldest request and return.

Other plausible policies include raising the maximum pool size after checking with some other objects that this is OK.

These cases can never occur if the maximum pool size is unbounded or the queue is unbounded. In these cases you instead face potential resource exhaustion.) The execute method does not throw any checked exceptions in any of these cases since any errors associated with them must normally be dealt with via handlers or callbacks. (Although in some cases, these might be associated with throwing unchecked exceptions.) You may wish to add special implementations even if you choose one of the listed policies. For example, the supplied Discard policy does not inform the caller of the drop. You could add your own version that does so. Since choice of policies is normally a system-wide decision, selecting a policy affects all calls to execute. If for some reason you would instead like to make per-call decisions, you could add variant versions of the execute method (for example, executeIfWouldNotBlock) in subclasses.

Thread construction parameters

A settable ThreadFactory establishes each new thread. By default, it merely generates a new instance of class Thread, but can be changed to use a Thread subclass, to set priorities, ThreadLocals, etc.

Interruption policy

Worker threads check for interruption after processing each command, and terminate upon interruption. Fresh threads will replace them if needed. Thus, new tasks will not start out in an interrupted state due to an uncleared interruption in a previous task. Also, unprocessed commands are never dropped upon interruption. It would conceptually suffice simply to clear interruption between tasks, but implementation characteristics of interruption-based methods are uncertain enough to warrant this conservative strategy. It is a good idea to be equally conservative in your code for the tasks running within pools.

Shutdown policy

The interruptAll method interrupts, but does not disable the pool. Two different shutdown methods are supported for use when you do want to (permanently) stop processing tasks. Method shutdownAfterProcessingCurrentlyQueuedTasks waits until all current tasks are finished. The shutDownNow method interrupts current threads and leaves other queued requests unprocessed.

Handling requests after shutdown

When the pool is shutdown, new incoming requests are handled by the blockedExecutionHandler. By default, the handler is set to discard new requests, but this can be set with an optional argument to method shutdownAfterProcessingCurrentlyQueuedTasks.

Also, if you are using some form of queuing, you may wish to call method drain() to remove (and return) unprocessed commands from the queue after shutting down the pool and its clients. If you need to be sure these commands are processed, you can then run() each of the commands in the list returned by drain().

Usage examples.

Probably the most common use of pools is in statics or singletons accessible from a number of classes in a package; for example:

 class MyPool {
 // initialize to use a maximum of 8 threads.
 static PooledExecutor pool = new PooledExecutor(8);
 }
 

1. Using a bounded buffer of 10 tasks, at least 4 threads (started only when needed due to incoming requests), but allowing up to 100 threads if the buffer gets full.

    pool = new PooledExecutor(new BoundedBuffer(10), 100);
    pool.setMinimumPoolSize(4);
    

2. Same as (1), except pre-start 9 threads, allowing them to die if they are not used for five minutes.

    pool = new PooledExecutor(new BoundedBuffer(10), 100);
    pool.setMinimumPoolSize(4);
    pool.setKeepAliveTime(1000 * 60 * 5);
    pool.createThreads(9);
    

3. Same as (2) except clients block if both the buffer is full and all 100 threads are busy:

    pool = new PooledExecutor(new BoundedBuffer(10), 100);
    pool.setMinimumPoolSize(4);
    pool.setKeepAliveTime(1000 * 60 * 5);
    pool.waitWhenBlocked();
    pool.createThreads(9);
    

4. An unbounded queue serviced by exactly 5 threads:

    pool = new PooledExecutor(new LinkedQueue());
    pool.setKeepAliveTime(-1); // live forever
    pool.createThreads(5);
    

Usage notes.

Pools do not mesh well with using thread-specific storage via java.lang.ThreadLocal. ThreadLocal relies on the identity of a thread executing a particular task. Pools use the same thread to perform different tasks.

If you need a policy not handled by the parameters in this class consider writing a subclass.

Version note: Previous versions of this class relied on ThreadGroups for aggregate control. This has been removed, and the method interruptAll added, to avoid differences in behavior across JVMs.

[ Introduction to this package. ]

 List tasks = pool.drain();
 for (Iterator it = tasks.iterator(); it.hasNext();) 
 ( (Runnable)(it.next()) ).run();