JDK thread pool parameters detailed analysis

 

In jdk it provides three ways to create a thread pool for us, but Ali coding standards which are expressly prohibit the use of these three api to create a thread pool, recommended us to a custom thread pool. why?

 

To answer why, we need to understand to create a thread pool, the role of each parameter:

First we look at three api jdk provide to create a thread pool:

1. newFixedThreadPool thread pool that creates a fixed number of threads.

 

 

2. newSingleThreadExecutor create a single-threaded thread pool

 

 3. newCachedThreadPool create a thread pool with cache

 

 

They found several ways to create a thread pool api, are essentially dependent on the ThreadPoolExecutor class to create a thread pool.

 

Then we look at the parameters required when ThreadPoolExecutor create a thread pool, as well as its role.

 

Create a thread pool, you need seven parameters.

1. corePoolSize: a core number of threads in the thread pool. The initial thread is not created. When a job is submitted to the thread pool to determine if the number of threads that have been created less than the number of cores, and there is no idle thread, it will create a new thread to perform the task submitted. If you have reached the number of kernel threads, it will be added to the blocking queue.

2.maximumPoolSize: maximum capacity of the thread pool. When the thread pool filled with blocking queue, and the number of threads in the thread pool has not yet reached the maximum number of threads, it will create a new thread, until it reaches the maximum value

When 3.keepAliveTime when blocking queue inside the task to be performed over, and there is idle threads, the survival time is greater than the specified number of kernel thread pool idle threads part, after all, is the need to thread consumption of resources, timely recovery is necessary. When the thread is idle for more than this time, it will recover lost part of idle threads, so the number of threads in the thread pool is not greater than the core thread

 4.unit keepAliveTIme and supporting the use of time values ​​specified above, but does not specify the unit time (hours, minutes, seconds, etc.), where the unit of time required to specify

5.workQueue blocking queue when there is no idle thread, redundant tasks cache place.

6.threadFactory thread factory used when creating a thread, set some parameters thread. Usually we see the log in order to facilitate follow-up, we can specify a custom thread pool thread through this name

7.handler when the maximum number of threads and blocking queue slow, when submitting follow-up mission, no place can be given the task of continuing the submission. In this case a denial strategy.

 

Refused strategy jdK, provides four:

// tasks submitted by the task execution thread 
public  static  class the CallerRunsPolicy the implements RejectedExecutionHandler { 

        public the CallerRunsPolicy () {} 


        public  void rejectedExecution (R & lt the Runnable, the ThreadPoolExecutor E) {
             IF (! {E.isShutdown ()) 
                r.run (); 
            } 
        } 
    }     // do not receive a new task, directly thrown
     

public  static  class AbortPolicy the implements RejectedExecutionHandler { 
    
        public AbortPolicy () {} 


        public  voidrejectedExecution (R & lt the Runnable, the ThreadPoolExecutor E) {
             the throw  new new RejectedExecutionException ( "the Task" r.toString + () + 
                                                 "Rejected from" + 
                                                 e.toString ()); 
        } 
    }     // do not receive no exception is thrown, to achieve air, ignores the task
     


public  static  class DiscardPolicy the implements RejectedExecutionHandler { 
   
        public DiscardPolicy () {} 

        public  void rejectedExecution (R & lt the Runnable, the ThreadPoolExecutor E) { 
        } 
    } 

    // discard the oldest tasks, the first task is removed from the blocking queue submitted, and then the task is added. 
    public  static class DiscardOldestPolicy implements RejectedExecutionHandler {

        public DiscardOldestPolicy() { }


        public void rejectedExecution(Runnable r, ThreadPoolExecutor e) {
            if (!e.isShutdown()) {
                e.getQueue().poll();
                e.execute(r);
            }
        }
    }

 

 

Explaining create a line over the pool, the role of each parameter, we now see why not let our turn to create a thread pool using apI jdk provided, but we need a custom thread pool.

newFixedThreadPool, newSingleThreadExecutor both api use of blocking queue is unbounded queue, that is, no matter how many tasks, we are receiving. Our memory is limited, blocking queue inside the store task is more, it means more memory used, this will lead to consume a lot of memory, easily lead to OOM

newCachedThreadPool api and this blocking queue capacity is 0, the maximum value for the maximum number of threads of Integer. Whenever there is a job submission time, blocking queue can not store, will open a new thread when compared to multi-task, it will create a large number of threads, causing OOM.

 

That's why we use the thread pool must be self-defined reason the thread pool.