线程池的拒绝策略
- AbortPolicy：直接抛出异常阻止系统正常工作。
- CallerRunsPolicy：只要线程池未关闭，该策略直接在调用者线程中，运行当前被丢弃的任务。
- DiscardOldestPolicy：丢弃最老的一个请求，尝试再次提交当前任务。
- DiscardPolicy：丢弃无法处理的任务，不给予任何处理。
- 如果需要自定义拒绝策略可以实现RejectedExecutionHandler接口
如何使用好线程池
线程个数大小的设置
计算密集型
- 顾名思义就是应用需要非常多的CPU计算资源，在多核CPU时代，我们要让每一个CPU核心都参与计算，将CPU的性能充分利用起来，这样才算是没有浪费服务器配置，如果在非常好的服务器配置上还运行着单线程程序那将是多么重大的浪费
- 对于计算密集型的应用，完全是靠CPU的核数来工作，所以为了让它的优势完全发挥出来，避免过多的线程上下文切换，比较理想方案是： 线程数 = CPU核数+1，也可以设置成CPU核数*2，但还要看JDK的版本以及CPU配置(服务器的CPU有超线程)
IO密集型
- 就很好理解了，我们现在做的开发大部分都是WEB应用，涉及到大量的网络传输，不仅如此，与数据库，与缓存间的交互也涉及到IO，一旦发生IO，线程就会处于等待状态，当IO结束，数据准备好后，线程才会继续执行
- 因此从这里可以发现，对于IO密集型的应用，我们可以多设置一些线程池中线程的数量，这样就能让在等待IO的这段时间内，线程可以去做其它事，提高并发处理效率。那么这个线程池的数据量是不是可以随便设置呢？当然不是的，请一定要记得，线程上下文切换是有代价的
- 目前总结了一套公式，对于IO密集型应用： 线程数 = CPU核心数/(1-阻塞系数) 这个阻塞系数一般为0.8~0.9之间，也可以取0.8或者0.9。 套用公式，对于双核CPU来说，它比较理想的线程数就是20，当然这都不是绝对的，需要根据实际情况以及实际业务来调整：final int poolSize = (int)(cpuCore/(1-0.9))
线程池相关参数配置
- 使用线程池的时候都不要选择没有上限限制的配置项。 第一，我们不要去使用没有上限的线程池和设置无界队列！ 比如，newCachedThreadPool的设置与无界队列的设置因为某些不可预期的情况，线程池会出现系统异常，导致线程暴增的情况或者任务队列不断膨胀，内存耗尽导致系统崩溃和异常。 我们推荐使用自定义线程池来避免该问题，这也是在使用线程池规范的首要原则
- 合理设置线程数量、和线程空闲回收时间，根据具体的任务执行周期和时间去设定，避免频繁的回收和创建，虽然我们使用线程池的目的是为了提升系统性能和吞吐量，但是也要考虑下系统的稳定性，不然出现不可预期问题会很麻烦
- 根据实际场景，选择适用于自己的拒绝策略。进行补偿，不要乱用JDK支持的自动补偿机制！尽量采用自定义的拒绝策略去进行兜底
利用Hook嵌入你的行为
- 利用Hook，留下线程池执行轨迹： ThreadPoolExecutor提供了protected类型可以被覆盖的钩子方法，允许用户在任务执行之前和执行之后做一些事情。
- 我们可以通过它来实现比如初始化ThreadLocal、收集统计信息、如记录日志等操作。这类Hook如beforeExecute和afterExecute。
- 另外还有一个Hook可以用来在任务被执行完的时候让用户插入逻辑，如rerminated 。 如果hook方法执行失败，则内部的工作线程的执行将会失败或被中断
线程池的关闭
- 内容当线程池不在被引用并且工作线程数为0的时候，线程池将被终止。我们也可以调用shutdown来手动终止线程池。如果我们忘记调用shutdown，为了让线程资源被释放，我们还可以使用keepAliveTime和allowCoreThreadTimeOut来达到目的! 当然，稳妥的方式是使用虚拟机Runtime.getRuntime().addShutdownHook方法，手工去调用线程池的关闭方法
