Java thread pool work queue saturation policy code example

Thread pool is a practical tool for collecting parallel execution tasks. With the introduction of multi-core architecture suitable for application parallelization by CPU, the role of thread pool is becoming more and more obvious. Java 5 introduces this framework as a new concurrency support part through ThreadPoolExecutor class and other auxiliary classes.

The ThreadPoolExecutor framework is flexible and powerful. It supports user specific configurations and provides related hooks and saturation policies to handle full queues

The java thread pool will first place the submitted task in the work queue and obtain it from the work queue (the synchronous queue is directly submitted to the worker thread by the producer). Then there are two implementation strategies for work queue: unbounded queue and bounded queue. There is no saturation problem in the unbounded queue, but the problem is that when the request continues to be under high load, the task will mindlessly join the work queue, which may lead to overflow or depletion of resources such as memory. The bounded queue will not lead to the problem of memory depletion caused by high load, but it will lead to the problem of how to manage newly submitted tasks when the work queue is full, which is the problem to be solved by the thread pool work queue saturation strategy.

Saturation strategies are divided into abort strategy, callerruns strategy, discard strategy and discardolds strategy.

For a better understanding, I write a small example.

When the work queue is full, the processing methods of different policies are:

1. Abort policy: the default policy is to throw an unchecked exception rejectedexecutionexception directly when a new task is submitted, which can be caught by the caller. Add the following code to the main function:

The operation result is:

The program threw a rejectedexecutionexception and ran a total of 8 tasks (the thread pool can run 3 tasks at the beginning, and 5 queues are stored in the work queue). When the work queue is full, an exception is thrown directly, and the JVM never exits (I don't know why now). We can see that the threads executing tasks are all threads in the thread pool.

2. Callerruns policy: as the adjustment mechanism, it neither discards tasks nor throws exceptions, but returns some tasks to the caller. Instead of executing the new task in the thread of the thread pool, the new task is run in the thread that calls the exector.

Run in main function:

Operation results

All tasks are run, and 2 (10 - 3 - 5) tasks are successfully executed in the main thread, and 8 tasks are executed by threads in the thread pool. 3. Discard strategy: newly submitted tasks are discarded. Run in the main function

The above results show that no exception is thrown, the two new tasks submitted later are abandoned, only the first 8 (3 + 5) tasks are processed, and the JVM exits.

4. Discard old policy: queue the tasks of "team leader", and then try to submit new tasks. (not suitable for the scenario where the work queue is a priority queue)

Run the following method in the main function

Running results: a total of 8 tasks are run. The program ends. Task 9 and task 10 added later are executed, while task 3 and task 4 are discarded.

summary

The above is all about the java thread pool work queue saturation policy code example in this article. I hope it will be helpful to you. If there are deficiencies, please leave a message to point out. Thank you for your support.