[JAVA学习笔记-65]ThreadPoolExecutor参数解析

Exectors的几个static接口，底层调用的都是ThreadPoolExecutor，通过参数的变化来适应各种应用场景。


An ExecutorService that executes each submitted task using one of possibly several pooled threads, normally configured using Executors factory methods.
Thread pools address two different problems: they usually provide improved performance when executing large numbers of asynchronous tasks, due to reduced per-task invocation overhead, and they provide a means of bounding and managing the resources, including threads, consumed when executing a collection of tasks. Each ThreadPoolExecutor also maintains some basic statistics, such as the number of completed tasks.


To be useful across a wide range of contexts, this class provides many adjustable parameters and extensibility hooks. However, programmers are urged to use the more convenient Executors factory methods Executors.newCachedThreadPool() (unbounded thread pool, with automatic thread reclamation), Executors.newFixedThreadPool(int) (fixed size thread pool) and Executors.newSingleThreadExecutor() (single background thread), that preconfigure settings for the most common usage scenarios. Otherwise, use the following guide when manually configuring and tuning this class:


Core and maximum pool sizes
A ThreadPoolExecutor will automatically adjust the pool size (see getPoolSize()) according to the bounds set by corePoolSize (see getCorePoolSize()) and maximumPoolSize (see getMaximumPoolSize()). When a new task is submitted in method execute(java.lang.Runnable), and fewer than corePoolSize threads are running, a new thread is created to handle the request, even if other worker threads are idle. If there are more than corePoolSize but less than maximumPoolSize threads running, a new thread will be created only if the queue is full. By setting corePoolSize and maximumPoolSize the same, you create a fixed-size thread pool. By setting maximumPoolSize to an 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 are set only upon construction, but they may also be changed dynamically using setCorePoolSize(int) and setMaximumPoolSize(int).
【总结：就是线程池默认创建的时候没有idle线程待命，直到有新的task被提交；当task的数量未达到corePoolSize的大小，无论当前的工作线程是否有空闲，
线程池都会继续创建新的工作线程，直到达到corePoolSize；此时如果继续提交新的task，如果工作线程有空闲，则优先使用空闲的线程执行新的任务，如果没有
空闲的工作线程，则将新提交的task存入指定的任务队列；如果任务队列也满了，则线程池会继续创建新的工作线程（取决于maximumPoolSize的值）直到达到
muximumPoolSize，如果此时工作线程仍然不足以满足需求，则线程池会根据指定的reject policy处理。

可以指定线程池在创建的时候，就预先创建好一定数量的工作线程，提升初始任务的处理效率。

线程池的策略是，使用 [corePoolSize,maximumPoolSize]个工作线程，使用指定的queue来进行任务缓存，避免增加工作线程，只有当队列缓存不足时，才增加
工作线程，且设置上限。（限制工作线程的数量，可以控制内存的占用量，无界的线程池，在大量请求到来的时候可能瞬间耗尽系统内存）】


On-demand construction
By default, even core threads are initially created and started only when new tasks arrive, but this can be overridden dynamically using method prestartCoreThread() or prestartAllCoreThreads(). You probably want to prestart threads if you construct the pool with a non-empty queue.
【总结：工作线程从任务队列中取任务来执行，通常情况下，创建线程池时指定的任务队列为空，如果预先设置任务，再创建线程池，就需要预先创建一定数量的
工作线程。使用2个方法：prestartCoreThread()只创建一个工作线程；prestartAllCoreThreads() 创建 corePoolSize 个工作线程。】


Creating new threads
New threads are created using a ThreadFactory. If not otherwise specified, a Executors.defaultThreadFactory() is used, that creates threads to all be in the same ThreadGroup and with the same NORM_PRIORITY 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 when asked by returning null from newThread, the executor will continue, but might not be able to execute any tasks. Threads should possess the "modifyThread" RuntimePermission. If worker threads or other threads using the pool do not possess this permission, service may be degraded: configuration changes may not take effect in a timely manner, and a shutdown pool may remain in a state in which termination is possible but not completed.


Keep-alive times
If the pool currently has more than corePoolSize threads, excess threads will be terminated if they have been idle for more than the keepAliveTime (see getKeepAliveTime(java.util.concurrent.TimeUnit)). This provides a means of reducing resource consumption when the pool is not being actively used. If the pool becomes more active later, new threads will be constructed. This parameter can also be changed dynamically using method setKeepAliveTime(long, java.util.concurrent.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 when there are more than corePoolSizeThreads. But method allowCoreThreadTimeOut(boolean) can be used to apply this time-out policy to core threads as well, so long as the keepAliveTime value is non-zero.
【出于对系统资源的保护，线程池默认只维持corePoolSize个工作线程，超出这个值的工作线程，一旦idle，在指定的超时时长后就被销毁；动态的调用
allowCoreThreadTimeOut(boolean)方法，可以让线程池把idle的core threads也回收掉】

Queuing
Any BlockingQueue may be used to transfer and hold submitted tasks. The use of this queue interacts with pool sizing:
If fewer than corePoolSize threads are running, the Executor always prefers adding a new thread rather than queuing.
If corePoolSize or more threads are running, the Executor always prefers queuing a request rather than adding a new thread.
If a request cannot be queued, a new thread is created unless this would exceed maximumPoolSize, in which case, the task will be rejected.
【一句话：尽量少创建工作线程，尽量多缓存任务，超出极限的任务，执行reject policy】
There are three general strategies for queuing:   【任务队列的3种策略】
1.Direct handoffs. A good default choice for a work queue is a SynchronousQueue that hands off tasks to threads without otherwise holdingthem. Here, an attempt to queue a task will fail if no threads are immediately available to run it, so a new thread will be constructed. This policy avoids lockups when handling sets of requests that might have internal dependencies. Direct handoffs generally require unbounded maximumPoolSizes to avoid rejection of new submitted tasks. This in turn admits the possibility of unbounded thread growth when commands continue to arrive on average faster than they can be processed.
【SynchronousQueue不缓存task，这是一个FIFO队列，生产者线程进入队列，将task交给工作线程(消费者)，然后各自离开。使用 SynchronousQueue 需要配合 
maximumPoolSizes 的值使用，如果max值太小，则会没有足够的工作线程来处理不断提交的任务；或者说，使用 SynchronousQueue 时，线程池是无界的。
关于 SynchronousQueue ，需要单独开一节来分析。简要地说，线程通过此队列，将任务直接提交给工作线程，而不是将任务先缓存。
使用此处策略，适用于最通用的场景：即，无论任务间是否有依赖，在系统资源充足的前提下，任务提交给线程池的任务都是立即执行的(如果工作线程不足，则
立即创建一个)】

2.Unbounded queues. Using an unbounded queue (for example a LinkedBlockingQueue without a predefined capacity) will cause new tasks to wait in the queue when all corePoolSize threads are busy. Thus, no more than corePoolSize threads will ever be created. (And the value of the maximumPoolSize therefore doesn't have any effect.) This may be appropriate when each task is completely independent of others, so tasks cannot affect each others execution; for example, in a web page server. While this style of queuing can be useful in smoothing out transient bursts of requests, it admits the possibility of unbounded work queue growth when commands continue to arrive on average faster than they can be processed.
【有界与否，取决于是否给ArrayBlockingQueue或者LinkedBlockingQueue设置一个capacity；因为当 corePoolSize 数量的工作线程不足以应付提交的task时，
tasks会被缓存在队列中，换句话说，就是会被延迟执行，因此如果正在执行的task与未执行的任务有依赖关系，则不适合此配置。使用有界队列，适合任务之间
完全独立的场景】

3.Bounded queues. A bounded queue (for example, an ArrayBlockingQueue) helps prevent resource exhaustion when used with finite maximumPoolSizes, but can be more difficult to tune and control. Queue sizes and maximum pool sizes may be traded off for each other: Using large queues and small pools minimizes CPU usage, OS resources, and context-switching overhead, but can lead to artificially low throughput. If tasks frequently block (for example if they are I/O bound), a system may be 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 scheduling overhead, which also decreases throughput.
【这里插入一个对吞吐量的概念描述：对于不同的对象，如防火墙，路由器，港口，机场等，吞吐量意味着不同的概念。对于服务器来说，就是平均每秒能处理的
请求数。线程池的参数变化，影响到使用此线程池进行业务处理的进程的吞吐量。
使用有界队列对任务进行缓存，需要配合控制工作线程数的两个参数进行配置。使用较小的工作线程池，较大的队列，可有效控制资源消耗，但会降低吞吐量，系统
会显得处理能力不足；使用较大的工作线程池，较小的队列，可提升处理能力，但是会增加资源消耗，同时大量的工作线程增加里系统的调度成本，极端情况
下可能导致系统资源不足，造成吞吐量下降；需要在上述配置中寻找一个平衡点。】

Rejected tasks
New tasks submitted in method execute(java.lang.Runnable) will be rejected when the Executor has been shut down, and also when the Executor uses finite bounds for both maximum threads and work queue capacity, and is saturated. In either case, the execute method invokes the RejectedExecutionHandler.rejectedExecution(java.lang.Runnable, java.util.concurrent.ThreadPoolExecutor) method of its RejectedExecutionHandler. Four predefined handler policies are provided:
1.In the default ThreadPoolExecutor.AbortPolicy, the handler throws a runtime RejectedExecutionException upon rejection.
2.In ThreadPoolExecutor.CallerRunsPolicy, the thread that invokes execute itself runs the task. This provides a simple feedback control mechanism that will slow down the rate that new tasks are submitted.
3.In ThreadPoolExecutor.DiscardPolicy, a task that cannot be executed is simply dropped.
4.In ThreadPoolExecutor.DiscardOldestPolicy, if the executor is not shut down, the task at the head of the work queue is dropped, and then execution is 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 are designed to work only under particular capacity or queuing policies.

Hook methods
This class provides protected overridable beforeExecute(java.lang.Thread, java.lang.Runnable) and afterExecute(java.lang.Runnable, java.lang.Throwable) methods that are called before and after execution of each task. These can be 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 be done once the Executor has fully terminated.
If hook or callback methods throw exceptions, internal worker threads may in turn fail and abruptly terminate.

Queue maintenance
Method getQueue() allows access to the work queue for purposes of monitoring and debugging. Use of this method for any other purpose is strongly discouraged. Two supplied methods, remove(java.lang.Runnable) and purge() are available to assist in storage reclamation when large numbers of queued tasks become cancelled.

Finalization
A pool that is no longer referenced in a program AND has no remaining threads will be shutdown automatically. If you would like to ensure that unreferenced pools are reclaimed even if users forget to call shutdown(), then you must arrange that unused threads eventually die, by setting appropriate keep-alive times, using a lower bound of zero core threads and/or setting allowCoreThreadTimeOut(boolean).
【保证一个线程池无事可做，而没有被shutdown的同时，尽量少占用资源的方式，就是让每个任务在执行完毕后自动结束，并允许核心工作线程在idle时通过超时机制
销毁。】