JDK Thread pool principle

This is from a Java official document that needs to be read often,
Https://docs.oracle.com/javase/8/docs/api/index.html?java/util/concurrent/ExecutorService.html

An Executorservice-executes each submitted task using one of possibly several pooled threads, normally configured USI Ng Executors factory methods.
Thread Pools address different problems:they usually provide improved performance when executing large numbers of asy nchronous tasks, due to reduced per-task invocation overhead, and they provide a means of bounding and managing the Resour CES, including threads, consumed when executing a collection of tasks. Each threadpoolexecutor also maintains some basic statistics, such as the number of completed tasks.

To is useful across a wide range of contexts, this class provides many adjustable parameters and extensibility hooks. However, programmers is urged to use the more convenient executors factory methods Executors.newcachedthreadpool () (Unbou nded thread pool, with automatic thread reclamation), Executors.newfixedthreadpool (int) (fixed size thread pool) and EXECU Tors.newsinglethreadexecutor () (single background thread), which preconfigure settings for the most common usage scenarios. Otherwise, use the following if manually configuring and tuning this class:

The following is the thread pool core concept:
Core pool and maximum number of pools
Core and Maximum pool sizes
A Threadpoolexecutor'll automatically adjust the pool size (see Getpoolsize ()) According to the bounds set by Corepoolsi Ze (see getcorepoolsize ()) and maximumpoolsize (see Getmaximumpoolsize ()). When a new task was submitted in method execute (Runnable), and fewer than corepoolsize threads was running, a new thread is Created to handle the request, even if other worker threads is idle. If there is more than corepoolsize but less than maximumpoolsize threads running, a new thread would be created only if th E queue is full. By setting Corepoolsize and maximumpoolsize the same, you create a fixed-size thread pool. By setting Maximumpoolsize to a essentially unbounded value such as Integer.max_value, you allow the pool to accommodate An arbitrary number of concurrent tasks. Most typically, core and maximum pool sizes is set only upon construction, but they could also be changed dynamically using Setcorepoolsize (int) and setmaximumpoolsize (int).

Meet demand constructs
On-demand construction
By default, even core threads is initially created and started only when new tasks Arrive, but this can is overridden dynamically using method Prestartcorethread () or prestartallcorethreads (). You probably want to prestart threads if you construct the pool with a non-empty queue.

Create new Thread
Creating new threads
New threads is created using a threadfactory. If not otherwise specified, a executors.defaultthreadfactory () is used, which creates threads to all being in the same THREADG Roup and with the same norm_priority and Non-daemon status. By supplying a different threadfactory, you can alter the thread's name, thread group, priority, daemon status, etc. If a threadfactory fails to create a thread is asked by returning null from Newthread, the executor would continue, but M Ight not being able to execute any tasks. Threads should possess the "Modifythread" runtimepermission. If worker threads or other threads using the pool does not possess this permission, service could be degraded:configuration C Hanges effect in a timely manner, and a shutdown pool could remain in a state in which termination are possible But not completed.

Survival time
Keep-alive Times
If the pool currently had more than corepoolsize threads, excess threads would be terminated if they had been idle for MOR E than the KeepAliveTime (see Getkeepalivetime (Timeunit)). This provides a means of reducing resource consumption when the pool was not being actively used. If the pool becomes more active later, new threads'll be constructed. This parameter can also is changed dynamically using method Setkeepalivetime (long, timeunit). Using a value of Long.max_value timeunit.nanoseconds effectively disables idle threads from ever terminating prior to shut Down. By default, the Keep-alive policy applies only if there is more than corepoolsize threads. But Method Allowcorethreadtimeout (Boolean) can is used to apply the time-out policy to the core threads as well, so long as T He keepalivetime value is Non-zero.

Queue Policy
Queuing
Any blockingqueue is used to transfer and hold submitted tasks. The use of this queue interacts with pool sizing:
If fewer than corepoolsize threads is running, the Executor always prefers adding a new thread rather than queuing.
If corepoolsize or more threads is running, the Executor always prefers queuing a request rather than adding a new thread .
If a request cannot be queued, a new thread was created unless this would exceed maximumpoolsize, in which case, the task W Ill be rejected.
There is three general strategies for queuing:
Direct handoffs. A good default choice for a work queue was a synchronousqueue that hands off tasks to threads without otherwise holding the M. Here, an attempt to queue a task would fail if no threads is immediately available to run it, so a new thread would be C Onstructed. This policy avoids lockups if handling sets of requests that might has internal dependencies. Direct handoffs generally require unbounded maximumpoolsizes to avoid rejection of new submitted tasks. The turn admits the possibility of unbounded thread growth when commands continue to arrive on average faster than the Y can be processed.
unbounded queues. Using a unbounded queue (for example a linkedblockingqueue without a predefined capacity) would cause new tasks to wait in The queue when all corepoolsize threads is busy. Thus, no more than corepoolsize threads would ever be created. (and the value of the Maximumpoolsize therefore doesn ' t has any effect.) This could be appropriate if each task was completely independent of others, so the tasks cannot affect each others execution; For example, in a Web page server. While this style of queuing can is useful in smoothing out transient bursts of requests, it admits the possibility of Unbo unded Work queue Growth If commands continue to arrive on average faster than they can be processed.
bounded queues. A bounded queue (for example, an arrayblockingqueue) helps prevent resource exhaustion when used with finite Maximumpoolsi Zes, but can is more difficult to tune and control. Queue sizes and Maximum pool sizes May is traded off for each other:using large queues and small pools minimizes CPU USAG E, OS resources, and context-switching overhead, but can leads to artificially low throughput. If tasks frequently block (for example if they is I/O bound), a system may is able to schedule time for more threads than You otherwise allow. Use of small queues generally requires larger pool sizes, which keeps CPUs busier but may encounter unacceptable Schedulin G overhead, which also decreases throughput.

Reject Task
Rejected tasks
New tasks submitted in method execute (Runnable) is rejected when the Executor have been shut down, and also when the E Xecutor uses finite bounds for both maximum threads and work queue capacity, and is saturated. In either case, the Execute method invokes the Rejectedexecutionhandler.rejectedexecution (Runnable, Threadpoolexecutor) Method of its Rejectedexecutionhandler. Four predefined handler policies is provided:
In the default Threadpoolexecutor.abortpolicy, the handler throws a runtime rejectedexecutionexception upon rejection.
In Threadpoolexecutor.callerrunspolicy, the thread that invokes execute itself runs the task. This provides a simple feedback control mechanism, that would slow down the rate that new tasks is submitted.
In Threadpoolexecutor.discardpolicy, the a task, cannot be executed is simply dropped.
In Threadpoolexecutor.discardoldestpolicy, if the executor are not shut down, the task at the head of the work queue is DRO pped, and then execution are retried (which can fail again, causing this to be repeated.)
It is possible to define and use other kinds of rejectedexecutionhandler classes. Doing so requires some care especially when policies is designed to work only under particular capacity or queuing polici Es.

Hook method
Hook methods
This class provides protected overridable BeforeExecute (Thread, Runnable) and AfterExecute (Runnable, Throwable) methods T Hat is called before and after execution of each task. These can used to manipulate the execution environment; For example, Reinitializing threadlocals, gathering statistics, or adding log entries. Additionally, method terminated () can be overridden to perform any special processing that needs to is done once the EXECU Tor has fully terminated.
If Hook or callback methods throw exceptions, internal worker threads may in turn fail and abruptly terminate.

Queue Maintenance
Queue Maintenance
Method Getqueue () allows access to the work queue for purposes of monitoring and debugging. Use of the This method for any other purpose is strongly discouraged. Supplied methods, remove (Runnable) and Purge () is available to assist in storage reclamation when large numbers of Qu eued tasks become cancelled.

Terminate
Finalization
A pool that's no longer referenced in a program and have no remaining threads would be shutdown automatically. If you would like to ensure that unreferenced pools is reclaimed even if users forget to call Shutdown () and then you must a Rrange that unused threads eventually die, by setting appropriate keep-alive times, using a lower bound of zero core Threa DS and/or Setting Allowcorethreadtimeout (Boolean).
Extension example. Most extensions of this class override one or more of the protected hook methods. For example, this is a subclass, so adds a simple Pause/resume feature:

Example

 class PausableThreadPoolExecutor extends ThreadPoolExecutor {   private boolean isPaused;   private ReentrantLock pauseLock = new ReentrantLock();   private Condition unpaused = pauseLock.newCondition();   public PausableThreadPoolExecutor(...) { super(...); }   protected void beforeExecute(Thread t, Runnable r) {     super.beforeExecute(t, r);     pauseLock.lock();     try {       while (isPaused) unpaused.await();     } catch (InterruptedException ie) {       t.interrupt();     } finally {       pauseLock.unlock();     }   }   public void pause() {     pauseLock.lock();     try {       isPaused = true;     } finally {       pauseLock.unlock();     }   }   public void resume() {     pauseLock.lock();     try {       isPaused = false;       unpaused.signalAll();     } finally {       pauseLock.unlock();     }   } }

JDK Thread pool principle