Java thread pool--threadpoolexecutor

First, the thread pool processing process

After a task is submitted to the thread pool, its main processing flow is as follows:

A thread from being submitted (submit) to execution experiences the following processes:

• The thread pool determines whether threads in the core constructor are performing tasks, and if not, creates a new worker thread to perform the task. If the thread of the core thread constructor is performing the task, it enters the next process;
• The thread pool determines whether the work queue is full. If the work queue is not full, the newly submitted task is stored in the Task Force column. If the work queue is full, enter the next process;
• The thread pool determines whether its internal threads are in a working state. If not, a new worker thread is created to perform the task. If it is full, it is assigned to the saturation policy to handle this task.

When the thread pool executes the Excute method, there are four main scenarios:

1. If the currently running thread is less than corepoolsize, create a new thread to perform the task (need to obtain a global lock);2. If the thread running is equal to or more than Corepoolsize, the task is added to the blockingqueue;3. If the task cannot be joined to Blockingqueue (the queue is full and the number of threads running is less than maximumpoolsize), a new thread is created to handle the task (need to obtain a global lock)4. If a new thread is created that will cause the currently running thread to exceed maxiumpoolsize (the queue is full and the number of threads running is greater than or equal to Maximumpoolsize), the task will be rejected. and call the Rejectedexecutionhandler.rejectedexecution () method (the thread pool throws an exception and tells the caller "I can't accept the task Anymore");the thread pool takes the above process to design to reduce the number of times a global lock is acquired. after the online pool finishes preheating (the number of threads currently running is greater than or equal to corepoolsize), almost all of the Excute method calls perform step 2; 5, when a thread completes the task, it will take the next task from the queue to execute; 6, when a thread has nothing to do, more than a certain amount of time (KeepAliveTime), the thread pool will determine if the number of threads currently running is greater than corepoolsize, then it is stopped. So when all the thread pool tasks are finished, it eventually shrinks to the size of the Corepoolsize

An example of this is that you do not have to join the task first.

Assuming that the queue size is 10,corepoolsize to 3,maximumpoolsize of 6, then when 20 tasks are added, the order of execution is as follows: Perform task 1, 2, 3 first, and then the task 4~13 into the queue. When the queue is full, tasks 14, 15, 16 will be executed immediately, and task 17~20 will throw an exception. The final order is: 1, 2, 3, 14, 15, 16, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13.

Queued

All blockingqueue can be used to transfer and maintain submitted tasks. You can use this queue to interact with the pool size:

• If the thread running is less than corepoolsize, Executor always prefers to add new threads without queuing;
• If the thread running is equal to or more than corepoolsize, then Executor always prefers to join the request to the queue without adding a new thread;
• If the request cannot be queued, a new thread is created unless the thread is created beyond maximumpoolsize, in which case the task is rejected

There are three common strategies for queuing:

1. Submit Directly

The default option for the work queue is synchronousqueue, which will submit tasks directly to the thread without maintaining them. Here, if there is no thread available to run the task immediately, attempting to join the task to the queue will fail, and a new thread will be constructed. This policy avoids locking when processing a set of requests that may have internal dependencies. Direct submissions typically require unbounded maximumpoolsizes to avoid rejecting newly submitted tasks. This policy allows the possibility of an increase in the number of lines that are allowed to continue when the command arrives in a row that exceeds the average that the queue can handle.

2. Unbounded queue

Using unbounded queues (for example, linkedblockingqueue that do not have a predefined capacity) will cause all corepoolsize threads to be busy while the newer tasks are waiting in the queue. This way, the created thread will not exceed corepoolsize (therefore, the value of maximumpoolsize is not valid). When each task is completely independent of other tasks, that is, when task execution does not affect each other, it is appropriate to use an unbounded queue, for example, in a Web page server. This queueing can be used to handle transient burst requests, which allow the possibility of an increase in the number of lines that are allowed to occur when the command reaches an average of more than the queue can handle.

3. Bounded queue

When using limited maximumpoolsizes, bounded queues (such as arrayblockingqueue) help prevent resource exhaustion, but may be difficult to adjust and control. The queue size and maximum pool size may need to be compromised: using large queues and small pools minimizes CPU usage, operating system resources, and context switching overhead, but can result in artificially reduced throughput. If tasks are frequently blocked (for example, if they are I/O boundaries), the system may schedule more threads than you permit. Using small queues typically requires a large pool size, high CPU utilization, but may encounter unacceptable scheduling overhead, which can also reduce throughput

4. Rejected Tasks

New tasks submitted in Method execute (java.lang.Runnable) are rejected when Executor is closed and Executor uses a limited boundary for the maximum thread and work queue capacity and is already saturated. In both cases, The Execute method calls its Rejectedexecutionhandler Rejectedexecutionhandler.rejectedexecution (Java.lang.runnable,java.util.concurrent.threadpoolexecutor) method. The following four predefined handler policies are available:

• In the default threadpoolexecutor.abortpolicy , the handler is rejected and the runtime rejectedexecutionexceptionis thrown;
• In threadpoolexecutor.callerrunspolicy , the thread invokes the execute itself that runs the task. This strategy provides a simple feedback control mechanism, which can slow down the submission speed of new tasks;
• In Threadpoolexecutor.discardpolicy , the tasks that cannot be performed will be deleted;
• In Threadpoolexecutor.discardoldestpolicy , if the execution program has not been closed, the task in the head of the work queue is deleted, and then the execution of the program is retried (repeat this process if it fails again)

See also: http://blog.csdn.net/longeremmy/article/details/8231184

http://blog.csdn.net/shixing_11/article/details/7109471

Java thread pool--threadpoolexecutor