(1), definition:
Public threadpoolexecutor (int corepoolsize,
int Maximumpoolsize,
Long KeepAliveTime,
Timeunit Unit,
Blockingqueue<runnable> Workqueue,
Rejectedexecutionhandler handler)
(2), parameter description:
Corepoolsize refers to the size of the reserved thread pool.
Maximumpoolsize refers to the maximum size of the thread pool.
KeepAliveTime refers to the timeout for the end of an idle thread.
Unit is an enumeration that represents the units of a keepalivetime.
Workqueue represents the queue that holds the task.
Rejectedexecutionhandler Add the execution strategy after the task fails, you can call the thread pool's Setrejectedexecutionhandler () method, using a custom Rejectedexecutionhandler object to replace the existing policy.
(3), the specific process is as follows:
1, when the line Chengchigang is created, there is not a thread inside. The task queue is passed in as a parameter. However, even if there are tasks in the queue, the thread pool will not execute them immediately.
2. When the Execute () method is invoked to add a task, the thread pool makes the following judgments:
A. If the number of threads running is less than corepoolsize, create a thread to run the task immediately;
B. If the number of threads running is greater than or equal to corepoolsize, put this task into the queue.
C. If the queue is full and the number of threads running is less than maximumpoolsize, create a thread to run the task;
D. If the queue is full and the number of threads running is greater than or equal to maximumpoolsize, the thread pool throws an exception telling the caller "I can't accept the task anymore".
3, when a thread completes the task, it takes the next task from the queue to execute.
4, in addition, when the number of threads in the pool is greater than corepoolsize, the extra threads will wait for KeepAliveTime for a long time, if no request can be processed on their own destruction.
(4), queuing has three kinds of general strategy:
Direct submission. The default option for the Task Force column is
Synchronousqueue, it simply gives the task to the thread without maintaining it. Here, if there is no thread available to run the task immediately, attempting to join the queue will fail, so a new thread is constructed. This policy avoids locking when processing a request set that may have internal dependencies. Direct submissions typically require unbounded maximumpoolsizes to avoid rejecting newly submitted tasks. This policy allows for the possibility of growth without a line when the command arrives continuously in excess of the averages that the queue can handle.
unbounded queues. Use of unbounded queues (for example, without predefined capacity
LinkedblockingqueueWill cause the task to wait in the queue for all corepoolsize threads to be busy. This creates a thread that does not exceed the corepoolsize. (therefore, the value of the maximumpoolsize is also invalid.) It is appropriate to use a unbounded queue when each task is completely independent of other tasks, that is, when task execution does not affect each other, for example, in a Web page server. This queuing can be used to handle transient burst requests, which allow for the possibility of growth without a boundary path when the command arrives continuously over the average number of times the queue can handle.
bounded queues. When using a limited maximumpoolsizes, bounded queues (such as
ArrayblockingqueueHelps prevent resource depletion, but may be difficult to adjust and control. The queue size and maximum pool size may need to be compromised: the use of large queues and small pools minimizes CPU utilization, operating system resources, and context switching overhead, but can result in artificially low throughput. If tasks are frequently blocked (for example, if they are I/O boundaries), the system may schedule more threads than you would allow. Using small queues typically requires larger pool sizes, higher CPU usage, but may experience unacceptable scheduling overhead, which can also reduce throughput.
(5), add 4 execution strategy after failure of task
Threadpoolexecutor.abortpolicy: Indicates a reject task and throws an exception
Threadpoolexecutor.discardpolicy: rejects the task but does not do any action
Threadpoolexecutor.callerrunspolicy: Represents a reject task and executes it directly in the caller's thread
Threadpoolexecutor.discardoldestpolicy: Indicates that the first task in the task queue is discarded first, and then the task is added to the queue.
Eg: use a bounded queue strategy.
Assuming that the queue size is 10,corepoolsize to 3,maximumpoolsize 6, then when 20 tasks are added, the order of execution is this: first perform tasks 1, 2, 3, and then task 4-13 is placed in the queue. When the queue is full, tasks 14, 15, 16 are executed immediately, and task 17-20 adds failure. The final order is: 1, 2, 3, 14, 15, 16, 4, 5, 6, 7, 8, 9, 10, 11, 12.
public class Threadpoolexe {
class Task implements Runnable {
private String name;
Public Task (String name) {
this.name = name;
}
public void Run () {
System.out.println ("the" + Name + "task");
try {
//simulate the time the thread needs to execute
thread.sleep (20000);
} catch (Interruptedexception e) {
//TODO auto-generated Catch block
e.printstacktrace ();
}} public void Execute () {
Threadpoolexecutor threadPool = new Threadpoolexecutor (3,6,3,timeunit.seconds, new Arrayblockingqueue<runnable> (a), New Threadpoolexecutor.discardpolicy ());
for (int i = 1; i<=20;i++) {
Task task = new Task ("" +i);
Threadpool.execute (Task);
}
public static void Main (string[] args) {
Threadpoolexe t = new Threadpoolexe ();
T.execute ();
}
Output results:
The 1 task
The 3 task
The 2 task
the task
The Task
Task
The 4 task
the 6 task< br> The 5 task
The 7 task
The 8 task
The 9 task
The task
The task
The task
the TAS K
