ThreadPoolExecutor's rejection policy RejectedExecutionHandler

Concurrent Programming - Thread Pool Executor (1)

http://blog.csdn.net/qq924862077/article/details/75305297

When analyzing the construction parameters of ThreadPoolExecutor , there is a RejectedExecutionHandler parameter.

RejectedExecutionHandler is an interface:
public interface RejectedExecutionHandler {
    void rejectedExecution(Runnable r, ThreadPoolExecutor executor);
}


There is only one method in it. When the number of threads to be created is greater than the maximum number of threads in the thread pool, the new task will be rejected and this method in this interface will be called.

You can implement this interface yourself to handle these excess tasks.

ThreadPoolExecutor itself has provided four rejection policies, namely CallerRunsPolicy, AbortPolicy, DiscardPolicy, DiscardOldestPolicy.
These four rejection policies are actually very

simple
at first glance. The custom rejection policy can be seen by looking at the four rejection policies provided by the previous system. Out, the implementation of the rejection strategy is very simple. The same is true if you write it yourself. For
example you want to execute the rejected task in a new thread, you can write it like this:
static class MyRejectedExecutionHandler implements RejectedExecutionHandler {
    @Override
    public void rejectedExecution(Runnable r, ThreadPoolExecutor executor) {
        new Thread(r,"new thread"+new Random().nextInt(10)).start();
    }
}

Then use normally:
ThreadPoolExecutor executor = new ThreadPoolExecutor(1, 2, 30,
        TimeUnit.SECONDS,
        new LinkedBlockingDeque<Runnable>(2),
        new MyRejectedExecutionHandler());


Reference: http://blog.csdn.net/qq_25806863/article/details/71172823

The pit of the java multi-threaded ThreadPoolExecutor strategy,
whether using jdk's thread pool ThreadPoolExecutor or spring's thread pool ThreadPoolTaskExecutor will use a blocking queue to store threads Task.

   When there are not enough threads, the subsequent tasks are temporarily stored in the blocking queue, waiting for an idle thread to proceed.

  When the blocking queue is full, there will be two situations where

   the number of running threads is less than the maximumPoolSize, then you still need to create threads to run the task;

   if the number of running threads is greater than or equal to the maximumPoolSize, then the thread pool will use a policy to Subsequent tasks are processed.
Reference: https://www.cnblogs.com/lic309/p/4564507.html

Detailed ThreadPoolExecutor
http://blog.csdn.net/lipc_/article/details/52025993

Java Executor Concurrency Framework (3) ThreadFactory Introduction
http:/ /blog.csdn.net/pfnie/article/details/52756738

ThreadPoolExecutor thread pool parameter setting
skillshttps ://www.cnblogs.com/waytobestcoder/p/5323130.html

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=326393391&siteId=291194637