The influence of bounded and unbounded queues on threadpoolexcutor execution

The influence of bounded and unbounded queues on threadpoolexcutor execution

Ava provides a 4-clock thread pool: Newcachedthreadpool newfixedthreadpool newsinglethreadexecutor Newscheduledthreadpool You can instantiate these four thread pools by executors.
Check the source will find that these four thread pools are directly or indirectly obtained threadpoolexecutor instances, but the parameters passed when the instantiation is not the same. So if the four kinds of Java-provided thread pools don't meet our needs, we can create a custom thread pool.
The Threadpoolexecutor method is constructed as follows:
which
Corepoolsize: The size of the core pool. When a task arrives, a thread is created to perform the task, and when the number of threads in the thread pool reaches corepoolsize, the incoming task is placed in the cache queue
Maximumpoolsize: Thread pool Maximum number of threads, which indicates how many threads can be created in a thread pool;
KeepAliveTime: Indicates when a thread does not perform a task for as long as it terminates.
Unit: Parameter KeepAliveTime, with 7 values, and 7 static properties in the Timeunit class:
[Plain] View plain copy timeunit.days;             Days Timeunit.hours;           Hour timeunit.minutes;           Minute timeunit.seconds;      Second timeunit.milliseconds;      Millisecond timeunit.microseconds;       Delicate timeunit.nanoseconds; Nanosecond workqueue: A blocking queue that stores the tasks waiting to be performed. In general, there are several options for blocking queues here:
[Java] View plain copy arrayblockingqueue;     Linkedblockingqueue; Synchronousqueue threadfactory: Thread factory, mainly used to create threads;
Handler: Represents the following four values when a policy is rejected when processing a task:
Threadpoolexecutor.abortpolicy: Discards the task and throws the rejectedexecutionexception exception.
Threadpoolexecutor.discardpolicy: Also discards the task, but does not throw an exception.
Threadpoolexecutor.discardoldestpolicy: Discard the task at the top of the queue and try to perform the task again (Repeat this procedure)
Threadpoolexecutor.callerrunspolicy: As long as the thread pool does not close, the policy runs directly on the caller thread, running the currently discarded task
Personally think that the 4 strategy is unfriendly, it is best to define a rejection policy, implement Rejectedexecutionhandler interface

The following focuses on the effect of queues that store waiting to perform on thread pool execution.
I. Bounded queues1. The initial poolsize < Corepoolsize, the submitted runnable task, will be directly executed as a thread parameter for new. 2. When the number of tasks submitted exceeds corepoolsize, the current runable is submitted to a block queue. 3. After the bounded queue is full, if poolsize < Maximumpoolsize, will try new one thread for emergency treatment, immediately carry out the corresponding runnable task. 4. If 3 is also unable to process, it will go to step fourth to perform the reject operation.
[java]  View Plain  copy public class threadpoolexcutortest implements runnable  {                      public String name;               Public threadpoolexcutortest (string name)  {            this.name = name;       }                @Override        public void  Run ()  {           system.out.println (name);           try {                thread.sleep (1000);            } catch  (interruptedexception e)  {                e.printstacktrace ();           }                   }              public static void main (string[)  args)  {           BlockingQueue<Runnable>  workQueue = new ArrayBlockingQueue<> (3);            threadpoolexecutor threadpool = new threadpoolexecutor (                                1, //corePoolSize                                 2,  //maximumPoolSize