Java Thread Pool Series (1)-threadpoolexecutor Implementation Principle _ Multithreading

Preface

Do Java development, generally can not avoid to face Java thread pool technology, such as Tomcat and other containers naturally support multithreading. Even if it is biased back-end technology, such as processing some messages, performing some computational tasks, it is often necessary to use the thread pooling technology. Given the importance of thread pooling technology, the next step is to introduce the underlying mechanism of the threadpoolexecutor thread pool implementation provided in Java. Only the mechanism of the chest, in order to better control this weapon.

Thread Pooling Technology Demo process

Key Concepts:
If it's easiest to understand how the thread pool works, it's a step-by-step dynamic demo. For ease of understanding, here are some concepts that are used in several thread pools.

Threadpoolexecutor: This is the thread pool implementation class that dynamically creates multiple threads and executes multiple committed tasks concurrently;

worker: is a runnable implementation class, the internal will create a thread, has been looping continuously perform tasks, so you can think of a worker is a worker thread;

corepoolsize: When the number of bus threads in the pool <corepoolsize, commit a task to create a new thread, regardless of whether the existing threads are idle, usually once the thread reaches
To the corepoolsize, then the number of bus threads in the pool will not fall below the corepoolsize. (unless Allowcorethreadtimeout=true and keepalivetime>0);

maximumpoolsize: When the number of threads in the pool reaches Corepoolsize, the newly submitted tasks are placed in the wait queue, which is typically executed by the corepoolsize thread created earlier. When the task submission speed is too fast, the queue is full, this time, if the current bus number <maximumpoolsize, then the line Cheng create a new thread to perform the newly submitted task, otherwise discard the task according to the policy;

KeepAliveTime: survival time, divided into two situations: (1) allowcorethreadtimeout=true, all threads, once created, within KeepAliveTime time, if no tasks can be performed, The thread exits and destroys, and the advantage is that the thread resource can be reclaimed when the system is not busy, (2) Allowcorethreadtimeout=false, if the bus path number is <=corepoolsize, then these threads will not exit. They are constantly waiting for the task to execute, even if there is no task currently, but if the thread counts >corepoolsize, and once a thread is idle for more than
KeepAliveTime will exit, but once lowered to corepoolsize, it will not exit again.

allowcorethreadtimeout: used to determine whether all threads can be recycled in the system's leisure time, and if it is allowcorethreadtimeout=true, it must be used in conjunction with KeepAliveTime. Used to decide whether to recycle these threads when the number of threads is <corepoolsize.

Workqueue: This is a blocking queue, when the number of threads >=corepoolsize, the task submitted will be placed in the blocking queue, if the blocking queue is unbounded, then the total number of threads is impossible to >corepoolsize, That is, the maximumpoolsize attribute is useless; if the blocking queue is bounded and is not full, the task is queued, otherwise the maximumpoolsize is judged to be a new thread to perform the task or to discard the task according to the policy.

With the above concept, the following two scenarios will be presented according to the value of allowcorethreadtimeout.

Demo One: Allowcorethreadtimeout=true

1, the initial value set: corepoolsize=2; maximumpoolsize=3;keepalivetime=10s; workqueue capacity is 2; The initial state diagram looks like this:

2, submit a task A, due to the number of bus threads 0<corepoolsize; at this time will create a thread to perform task A, the state diagram is as follows:

3, submit a task B, due to the number of bus threads 1<corepoolsize, this will create a thread to perform task B, the state diagram is as follows:

4, submit a task C, due to the bus path number 2=corepoolsize,workqueue dissatisfaction, this time the task C into the queue, the state diagram is as follows:

5, submit a task D, it is clear that the task D into the queue, the status diagram is as follows:

6, submit a task E, this time, the number of threads 2=corepoolsize,workqueue is full, to determine the number of threads found 2<maximumpoolsize, so continue to create the thread execution task E, the status diagram is as follows:

7, submit a task F, this time, 2=corepoolsize,workqueue is full, to determine the number of threads found 3=maximumpoolsize, in this case, the thread pool will be based on the policy to decide whether to discard the current task, Or you can delete a task in Workqueue, then join a new task, or customize the policy, such as persisting to DB or alerting. We assume that the policy is directly discarded, and the state diagram is unchanged.

8, this will not be a new task arrived, each task has been executed, including the queue of C and D also executed, at this time, because the current scene is Allowcorethreadtimeout=true, If the thread is still unable to get the new task after waiting for the KeepAliveTime time, the thread will exit itself, which will cause all threads to exit and then return to the original state again, as shown in the following illustration:

It's simpler to say: when Allowcorethreadtimeout=true, if a thread waits for the KeepAliveTime to get a new task, quit.

Demo II: Allowcorethreadtimeout=false

The steps and status of the 1~7 are the same as "demo one", so there is no more detail here, and the state diagram is as follows:

8, this will not be a new task arrived, each task has been executed, including the queue of C and D also executed, at this time, because the current scene is Allowcorethreadtimeout=false, and the number of threads 3>corepoolsize, At this point each thread is aware of the number of threads, so they will try to stop the end of the implementation will only stop a thread, the number of remaining threads 2=corepoolsize, then, even if there is no new task, this corepoolsize thread will not quit, have been alive waiting to receive the task. At this point, the status diagram is as follows:

status of the thread pool

The previous section shows the basic implementation of the thread pool, which describes the state of the thread pool, which is summarized in 5 states, as shown in the following illustration:

Running Status:
When you create a thread pool, the thread pool's initial state is RUNNING, and then you can submit the task execution.

Shutdown Status:
When shutdown () is invoked in the running state, the thread pool status is changed to shutdown, and when the submit task is rejected, a variety of rejection policies can be used.
For example, the simplest thing is to drop the task directly. As for the threads in progress, the execution will continue, and the tasks in the blocking queue will also be executed, and when all the tasks are finished, the thread pool will enter the tidying state, and after the execution of the Hook method terminated (), it will enter the final state terminated. The entire thread pool is completely terminated.

Stop Status:
When Shutdownnow () is invoked in the running state, the thread pool state is changed to stop, and when the submit task is rejected, what happens if there is a task executed to half. In fact, when executing shutdownnow (), the individual worker threads are interrupted, so how the task performs depends on what the task does, and whether it handles interrupt exceptions. And blocking queues have tasks that will no longer execute, and Shutdownnow () will return the list of failed tasks in the blocked queue after execution.

Tidying Status:
Tidying is only a transition state, when all worker threads are stopped, the thread pool state enters tidying, then executes a hook method terminated (), and the last thread pool enters the terminated state.

Terminated status:
thread pool termination state, this is nothing to say, we all understand.

Summary

Understanding the thread pool is primarily about understanding the main configuration parameters of the threading pool, and the principle is relatively straightforward without looking at the implementation details. To understand the principle of the basis of looking at the code, it will be twice the effort.