Java线程池的配置
1、ThreadPoolExecutor的重要参数
1、corePoolSize：核心线程数
* 核心线程会一直存活，及时没有任务需要执行
* 当线程数小于核心线程数时，即使有线程空闲，线程池也会优先创建新线程处理
* 设置allowCoreThreadTimeout=true（默认false）时，核心线程会超时关闭
2、queueCapacity：任务队列容量（阻塞队列）
* 当核心线程数达到最大时，新任务会放在队列中排队等待执行
3、maxPoolSize：最大线程数
* 当线程数>=corePoolSize，且任务队列已满时。线程池会创建新线程来处理任务
* 当线程数=maxPoolSize，且任务队列已满时，线程池会拒绝处理任务而抛出异常
4、 keepAliveTime：线程空闲时间
* 当线程空闲时间达到keepAliveTime时，线程会退出，直到线程数量=corePoolSize
* 如果allowCoreThreadTimeout=true，则会直到线程数量=0
5、allowCoreThreadTimeout：允许核心线程超时
6、rejectedExecutionHandler：任务拒绝处理器
* 两种情况会拒绝处理任务：
- 当线程数已经达到maxPoolSize，切队列已满，会拒绝新任务
- 当线程池被调用shutdown()后，会等待线程池里的任务执行完毕，再shutdown。如果在调用shutdown()和线程池真正shutdown之间提交任务，会拒绝新任务
* 线程池会调用rejectedExecutionHandler来处理这个任务。如果没有设置默认是AbortPolicy，会抛出异常
* ThreadPoolExecutor类有几个内部实现类来处理这类情况：
- AbortPolicy 丢弃任务，抛运行时异常
- CallerRunsPolicy 执行任务
- DiscardPolicy 忽视，什么都不会发生
- DiscardOldestPolicy 从队列中踢出最先进入队列（最后一个执行）的任务
* 实现RejectedExecutionHandler接口，可自定义处理器2、线程池队列的选择
wordQueue任务队列，用于转移和阻塞提交了的任务，即任务队列是运行线程的，任务队列根据corePoolSize和maximumPoolSize工作：
1.当正在运行的线程小于corePoolSize，线程池会创建新的线程
2.当大于corePoolSize而任务队列未满时，就会将整个任务塞入队列
3.当大于corePoolSize而且任务队列满时，并且小于maximumPoolSize时，就会创建新额线程执行任务
4、当大于maximumPoolSize时，会根据handler策略处理线程
任务队列有以下三种模式：
1. 直接提交。工作队列的默认选项是 SynchronousQueue，它将任务直接提交给线程而不保持它们。在此，如果不存在可用于立即运行任务的线程，则试图把任务加入队列将失败，因此会构造一个新的线程。此策略可以避免在处理可能具有内部依赖性的请求集时出现锁。直接提交通常要求无界 maximumPoolSizes 以避免拒绝新提交的任务。当命令以超过队列所能处理的平均数连续到达时，此策略允许无界线程具有增长的可能性。
2.无界队列。使用无界队列（例如，不具有预定义容量的 LinkedBlockingQueue）将导致在所有 corePoolSize 线程都忙时新任务在队列中等待。这样，创建的线程就不会超过 corePoolSize。（因此，maximumPoolSize 的值也就无效了。）当每个任务完全独立于其他任务，即任务执行互不影响时，适合于使用无界队列；例如，在 Web 页服务器中。这种排队可用于处理瞬态突发请求，当命令以超过队列所能处理的平均数连续到达时，此策略允许无界线程具有增长的可能性。
3.有界队列。当使用有限的 maximumPoolSizes 时，有界队列（如 ArrayBlockingQueue）有助于防止资源耗尽，但是可能较难调整和控制。队列大小和最大池大小可能需要相互折衷：使用大型队列和小型池可以最大限度地降低 CPU 使用率、操作系统资源和上下文切换开销，但是可能导致人工降低吞吐量。如果任务频繁阻塞（例如，如果它们是 I/O 边界），则系统可能为超过您许可的更多线程安排时间。使用小型队列通常要求较大的池大小，CPU 使用率较高，但是可能遇到不可接受的调度开销，这样也会降低吞吐量。
3、线程池的饱和策略
1.在默认的 ThreadPoolExecutor.AbortPolicy 中，处理程序遭到拒绝将抛出运行时 RejectedExecutionException。
2.在 ThreadPoolExecutor.CallerRunsPolicy 中，线程调用运行该任务的 execute 本身。此策略提供简单的反馈控制机制，能够减缓新任务的提交速度。
3.在 ThreadPoolExecutor.DiscardPolicy 中，不能执行的任务将被删除。
4.在 ThreadPoolExecutor.DiscardOldestPolicy 中，如果执行程序尚未关闭，则位于工作队列头部的任务将被删除，然后重试执行程序（如果再次失败，则重复此过程）。
定义和使用其他种类的 RejectedExecutionHandler 类也是可能的，但这样做需要非常小心，尤其是当策略仅用于特定容量或排队策略时。
public class Test { public static void main(String[] args) throws InterruptedException { //可以使用不同的abort和queue策略来看下执行的效果 RejectedExecutionHandler handler = new ThreadPoolExecutor.DiscardOldestPolicy (); ThreadPoolExecutor executor = new ThreadPoolExecutor(1, 2, 200, TimeUnit.MILLISECONDS, new LinkedBlockingDeque<>(2), handler); for (int i = 0; i < 30; i++) { MyTask myTask = new MyTask(i); try { executor.execute(myTask); }catch (RejectedExecutionException e){ System.out.println("task "+i+" 被放弃"); } System.out.println("线程池中线程数目：" + executor.getPoolSize() + "，队列中等待执行的任务数目：" + executor.getQueue().size() + "，已执行完的任务数目：" + executor.getCompletedTaskCount()); } //Thread.currentThread().sleep(400000); executor.shutdown(); } } class MyTask implements Runnable { private int taskNum; public MyTask(int num) { this.taskNum = num; } @Override public void run() { System.out.println("正在执行task " + taskNum); try { Thread.currentThread().sleep(1000); } catch (InterruptedException e) { e.printStackTrace(); } System.out.println("task " + taskNum + "执行完毕"); } }
4、线程池的配置策略
通常情况下，这是一个复杂的活。
1.根据任务性质设置
要想合理的配置线程池，就必须首先分析任务特性，可以从以下几个角度来进行分析：
1)任务的性质：CPU密集型任务，IO密集型任务和混合型任务。
2)任务的优先级：高，中和低。
3)任务的执行时间：长，中和短。
4)任务的依赖性：是否依赖其他系统资源，如数据库连接。
任务性质不同的任务可以用不同规模的线程池分开处理。CPU密集型任务配置尽可能小的线程，如配置CPU数+1个线程的线程池。IO密集型任务则由于线程并不是一直在执行任务，则配置尽可能多的线程，如2*CPU数。混合型的任务，如果可以拆分，则将其拆分成一个CPU密集型任务和一个IO密集型任务，只要这两个任务执行的时间相差不是太大，那么分解后执行的吞吐率要高于串行执行的吞吐率，如果这两个任务执行时间相差太大，则没必要进行分解。我们可以通过Runtime.getRuntime().availableProcessors()方法获得当前设备的CPU个数。
执行时间不同的任务可以交给不同规模的线程池来处理，或者也可以使用优先级队列，让执行时间短的任务先执行。
依赖数据库连接池的任务，因为线程提交SQL后需要等待数据库返回结果，如果等待的时间越长CPU空闲时间就越长，那么线程数应该设置越大，这样才能更好的利用CPU。
建议使用有界队列，有界队列能增加系统的稳定性和预警能力，可以根据需要设大一点，比如几千。我在测试一个线程池的时候，使用循环不断提交新的任务，造成任务积压在线程池，最后程序不断的抛出抛弃任务的异常。如果使用无界队列，线程池的队列就会越来越多，有可能会撑满内存，导致整个系统不可用，而不只是后台任务出现问题。
通常这种设置方式是比较粗略的方式。
2.利特尔法则
利特尔法则（Little’s law）是说，一个系统请求数等于请求的到达率与平均每个单独请求花费的时间之乘积
我们可以使用利特尔法则（Little’s law）来判定线程池大小。我们只需计算请求到达率和请求处理的平均时间。然后，将上述值放到利特尔法则（Little’s law）就可以算出系统平均请求数。若请求数小于我们线程池的大小，就相应地减小线程池的大小。与之相反，如果请求数大于线程池大小，事情就有点复杂了。
当遇到有更多请求待处理的情况时，我们首先需要评估系统是否有足够的能力支持更大的线程池。准确评估的前提是，我们必须评估哪些资源会限制应用程序的扩展能力。在本文中，我们将假定是CPU，而在实际中可能是其它资源。最简单的情况是，我们有足够的空间增加线程池的大小。若没有的话，你不得不考虑其它选项，如软件调优、增加硬件，或者调优并增加硬件。
具体的我们可以参考这篇文章：
http://www.infoq.com/cn/articles/Java-Thread-Pool-Performance-Tuning
3.配置文件中配置
如果是对系统性能非常重要的一个线程池，与其猜测该线程池的合理大小，不如将它的参数开放出来。因为线程池的合理大小和系统资源也是息息相关的，假设你在设备A上面的线程池大小已经是最优了，不见得把程序放到设备B上面同样是最优的。放在配置文件中，可以方便将来根据系统运行情况进行调整。
我们看看开源任务调度框架Quartz开放了哪些参数：
|
<!-- 线程执行器配置，用于任务注册 --> <bean id="executor"class="org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor"> <property name="corePoolSize"value="6" /> <property name="maxPoolSize"value="16" /> <property name="queueCapacity"value="500" /> </bean> |
Quart开放了核心线程数目、最大线程数目、任务队列的容量这三个重要的参数，他们的设置都是和系统资源息息相关的。
4、线程池的监控
通过线程池提供的参数进行监控。线程池里有一些属性在监控线程池的时候可以使用：
taskCount：线程池需要执行的任务数量。
completedTaskCount：线程池在运行过程中已完成的任务数量。小于或等于taskCount。
largestPoolSize：线程池曾经创建过的最大线程数量。通过这个数据可以知道线程池是否满过。如等于线程池的最大大小，则表示线程池曾经满了。
getPoolSize:线程池的线程数量。如果线程池不销毁的话，池里的线程不会自动销毁，所以这个大小只增不+ getActiveCount：获取活动的线程数。
通过扩展线程池进行监控。通过继承线程池并重写线程池的beforeExecute，afterExecute和terminated方法，我们可以在任务执行前，执行后和线程池关闭前干一些事情。如监控任务的平均执行时间，最大执行时间和最小执行时间等。
