- In the previous article, we know the meaning of thread pool parameters, including one parameter
handlerWe said that it is a rejection policy. We will analyze the specific rejection policy of thread pool in this article
- First of all, we need to understand the function of the rejection policy of the thread pool, which is used to deal with the processing mechanism when the thread pool cannot continue to process more tasks. First of all, we need to know the trigger time of the rejection policy. Let’s look at the following code:
ThreadPoolExecutor threadPoolExecutor = new ThreadPoolExecutor( 1, 2, 1, TimeUnit.MILLISECONDS, new LinkedBlockingQueue<>(), new ThreadPoolExecutor.DiscardOldestPolicy() );
When to reject thread pool
- First, when we normally close the thread pool, we use the
shutdownAt this time, even if there are unfinished tasks in the thread pool, because the thread pool has been closed, we will be rejected if we continue to submit tasks to the thread pool
- Second, when the thread pool has no ability to continue processing submitted tasks, such as the queue is full and the maximum number of threads is reached, the thread pool will be saturated
What we need to learn and understand is the second one. In actual development, we need to solve this situation. For the process of thread pool operation, please refer to our previous article, or pay attention to I- code.online Blog.
- First of all, we know that the type of the rejection policy parameter of the thread pool is
RejectedExecutionHandlerType, so we can first understand the relationship between this interface
- In the above class diagram, we can see that
RejectedExecutionHandlerThere are four implementation classes of the interface, and all of them provide parameterless constructors. These four implementation classes correspond to different rejection strategies and have their own applicable scenarios
AbortPolicyReject policy: this policy will directly throw a
RuntimeException, let you feel that the task has been rejected, so you can choose to retry or abandon the submission strategy according to the business logic.
DiscardPolicyRejection strategy: this strategy discards the submitted task directly when it is submitted, and will not give any prompt notice. Therefore, this strategy should be used with caution, because there are certain risks. For us, we do not know whether the submitted task has been discarded or not
DiscardOldestPolicyRejection strategy: this strategy is similar to the above. However, it discards the head node in the queue, that is, the one with the longest survival time
CallerRunsPolicyRejection strategy: this strategy is the most perfect. Compared with the other three, when the thread pool is unable to process the current task, it will hand over the execution right of the task to the submitting thread, that is, who submits the task is responsible. In this way, the submitted task will not be abandoned and cause business loss. At the same time, this strategy of who submits the task is responsible must let the submitting thread be responsible If the task is time-consuming, the thread submitting the task will be busy and unable to continue to submit the task during this period, which slows down the submission speed of the task, which is equivalent to a negative feedback. It also helps the threads in the thread pool to digest tasks
This article is published by anonystar and can be reprinted, but the source of the original should be stated.
Welcome to pay attention to wechat public account: yunqi code for more high-quality articles
More articles focus on the author’s blog:Yunqi code I- code.online