通过ThreadPoolExecutor#execute()提交任务时，若任务在执行的过程中出现运行时异常，会导致 执行任务的线程 终止。
但要命的是，有时任务虽然异常了，但你却收不到任何通知，你还在开心摸鱼，以为任务都执行很正常。虽然线程池提供了很多用于异常处理的方法，但最稳妥和简单的方案还是捕获所有异常并具体处理：
线程池的线程管理
还好有谷歌，一般我们直接利用guava的ThreadFactoryBuilder实现线程池线程的自定义命名即可。
线程池的拒绝策略
线程池默认的拒绝策略会抛RejectedExecutionException，这是个运行时异常，IDEA不会强制捕获，所以我们也很容易忽略它。
对于采用何种策略，具体要看任务的重要性：
- 若是一些不重要任务，可选择直接丢弃
- 重要任务，可采用降级，比如将任务信息插入DB或MQ，启用一个专门用作补偿的线程池去补偿处理。所谓降级，也就是在服务无法正常提供功能的情况下，采取的补救措施。具体处理方式也看具体场景而不同。
- 当线程数大于核心线程数时，线程等待keepAliveTime后还是无任务需要处理，收缩线程到核心线程数
了解这个策略，有助于我们根据实际的容量规划需求，为线程池设置合适的初始化参数。也可通过一些手段来改变这些默认工作行为，比如：
- 声明线程池后立即调用prestartAllCoreThreads，启动所有核心线程
- 传true给allowCoreThreadTimeOut，让线程池在空闲时同样回收核心线程
弹性伸缩的实现
线程池是先用Q存放来不及处理的任务，满后再扩容线程池。当Q设置很大时（那个 工具类），最大线程数这个参数就没啥意义了，因为队列很难满或到满时可能已OOM，更没机会去扩容线程池了。
是否能让线程池优先开启更多线程，而把Q当成后续方案？比如我们的任务执行很慢，需要10s，若线程池可优先扩容到5个最大线程，那么这些任务最终都可以完成，而不会因为线程池扩容过晚导致慢任务来不及处理。
难题在于：
- 线程池在工作队列满时，会扩容线程池
重写队列的offer，人为制造该队列满的条件 - 改变了队列机制，达到最大线程后势必要触发拒绝策略
实现一个自定义拒绝策略，这时再把任务真正插入队列
Tomcat就实现了类似的“弹性”线程池。
务必确认清楚线程池本身是不是复用的。
某服务偶尔报警线程数过多，但过一会儿又会降下来，但应用的请求量却变化不大。
可以在线程数较高时抓取线程栈，发现内存中有上千个线程池，这肯定不正常！
但代码里也没看到声明了线程池，最后发现原来是业务代码调用了一个类库：
该类库竟然每次都创建一个新的线程池！
newCachedThreadPool会在需要时创建必要数量的线程，业务代码的一次业务操作会向线程池提交多个慢任务，这样执行一次业务操作就会开启多个线程。如果业务操作并发量较大的话，的确有可能一下子开启几千个线程。
那为何监控中看到线程数量会下降，而不OOM？
newCachedThreadPool的核心线程数是0，而keepAliveTime是60s，所以60s后所有线程都可回收。
那这如何修复呢？
使用static字段存放线程池引用即可
线程池的意义在于复用，就意味着程序应该始终使用一个线程池吗？
不，具体场景具体分析。
比如一个 I/O 型任务，不断向线程池提交任务：向一个文件写入大量数据。线程池的线程基本一直处于忙碌状态，队列也基本满。而且由于是CallerRunsPolicy策略，所以当线程满队列满，任务会在提交任务的线程或调用execute方法的线程执行，所以不要认为提交到线程池的任务就一定会被异步处理。
毕竟，若使用CallerRunsPolicy，就有可能异步任务变同步执行。使用CallerRunsPolicy，当线程池饱和时，计算任务会在执行Web请求的Tomcat线程执行，这时就会进一步影响到其他同步处理的线程，甚至造成整个应用程序崩溃。
如何修正？
使用单独的线程池处理这种“I/O型任务”，将线程数设置多一些！
所以千万不要盲目复用别人写的线程池！因为它不一定适合你的任务！
Java 8的parallel stream
可方便并行处理集合中的元素，共享同一ForkJoinPool，默认并行度是CPU核数-1。对于CPU绑定的任务，使用这样的配置较合适，但若集合操作涉及同步I/O操作（比如数据库操作、外部服务调用），建议自定义一个ForkJoinPool（或普通线程池）。
最后声明一点：提交到相同线程池中的任务，一定要是相互独立的，最好不要有依赖关系！
参考
- 《阿里巴巴Java开发手册》
