Analysis of thread pool rejection policy

(1) AbortPolicy:

java.util.concurrent.RejectedExecutionException (trigger condition: number of threads = maximumPoolSize and queue is full), consequence: thread pool termination -- very serious, it proves that flow control is required, or the resource capacity needs to be expanded


(2 ) DiscardPolicy: The policy will quietly discard the newly submitted task (trigger condition: the number of threads = maximumPoolSize and the queue is full), the consequence: the new task data is discarded


(3) DiscardOldestPolicy: The old thread is discarded (trigger condition: the number of threads = maximumPoolSize and the queue Full), consequence: discard the old task data

(4) CallerRunsPolicy: that is, it is not executed by the threads in the thread pool, but is handed over to the caller for execution (trigger condition: the number of threads = maximumPoolSize and the queue is full), the consequence: exceeds the capacity The evaluated traffic will be handed over to the caller for slow execution.

I personally like to use CallerRunsPolicy, which can at least ensure the basic availability of the system (but it may drag down the CPU and JVM, and the CPU generally has an early warning, so the core goal of the peak period is to control the traffic) , of course, if your traffic data is allowed to be lost, use DiscardOldestPolicy, DiscardPolicy is the best strategy