咱们会使用各类池化技术缓存 建立性能开销较大的 对象，好比线程池、链接池、内存池。
它们的原理都是预先建立一些对象入池，使用时直接取出，用完归还以复用，还会经过策略调整池中缓存对象的数量，实现动态伸缩性。java
因为线程的建立比较昂贵，短平快的任务通常考虑使用线程池处理，而非直接建立线程。
手动声明线程池程序员
JDK的Executors工具类定义了不少便捷的方法能够快速建立线程池。web
可是阿里有话说：面试
咱们来看他说的弊端案例真的这么严重吗？
newFixedThreadPool 可能 OOM数据库
咱们写一段测试代码，来初始化一个单线程的FixedThreadPool，循环1亿次向线程池提交任务，每一个任务都会建立一个比较大的字符串而后休眠一小时：缓存
执行程序后不久，日志中就出现了以下OOM：多线程
Exception in thread “http-nio-45678-ClientPoller”
java.lang.OutOfMemoryError: GC overhead limit exceeded架构
1 2 newFixedThreadPool线程池的工做队列直接new了一个LinkedBlockingQueue 但其默认构造器是一个Integer.MAX_VALUE长度的队列，因此很快就队列满了
虽然使用newFixedThreadPool能够固定工做线程数量，但任务队列几乎无界。若是任务较多且执行较慢，队列就会快速积压，内存不够就很容易致使OOM。
newCachedThreadPool致使OOM并发
[11:30:30.487] [http-nio-45678-exec-1] [ERROR] [.a.c.c.C.[.[.[/].[dispatcherServlet]:175 ] - Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception [Handler dispatch failed; nested exception is java.lang.OutOfMemoryError: unable to create new native thread] with root cause
java.lang.OutOfMemoryError: unable to create new native thread框架
1 2
日志可见OOM是由于没法建立线程，newCachedThreadPool这种线程池的最大线程数是Integer.MAX_VALUE，可认为无上限，而其工做队列SynchronousQueue是一个没有存储空间的阻塞队列。
因此只要有请求到来，就必须找到一条工做线程处理，若当前无空闲线程就再建立一个新的。
因为咱们的任务需1小时才能执行完成，大量任务进来后会建立大量的线程。咱们知道线程是须要分配必定的内存空间做为线程栈的，好比1MB，所以无限建立线程必然会致使OOM：
public static ExecutorService newCachedThreadPool() {
return new ThreadPoolExecutor(0, Integer.MAX_VALUE,
60L, TimeUnit.SECONDS,
new SynchronousQueue());
1 2 3 4
开发同窗其实面试时都知道这俩线程池原理，只是抱有侥幸，以为只是使用线程池作了轻量任务，不会形成队列积压或开启大量线程。
案例
用户注册后，咱们调用一个外部服务去发送短信，发送短信接口正常时可在100ms内响应，TPS 100的注册量，CachedThreadPool能稳定在占用10个左右线程的状况下知足需求。在某个时间点，外部短信服务不可用了，咱们调用这个服务的超时又特别长， 好比1分钟，1分钟可能就进来了6000用户，产生6000个发送短信的任务，须要6000个线程，没多久就由于没法建立线程致使了OOM。
因此阿里也不建议使用Executors提供的两种方便线程池建立方式：
需根据本身的场景、并发状况来评估线程池的几个核心参数，包括核心线程数、最大线程数、线程回收策略、工做队列的类型，以及拒绝策略，确保线程池的工做行为符合需求，通常都须要设置有界的工做队列和可控的线程数 任什么时候候都应为自定义线程池指定有意义的名称，以方便排查问题。当出现线程数量暴增、线程死锁、线程占用大量CPU、线程执行出现异常等问题时，每每会抓取线程栈。此时，有意义的线程名称，就能够方便定位问题。
除手动声明线程池外，推荐用些监控手段观察线程池状态。线程池这个组件每每会表现得不辞辛苦、默默无闻，除非出现拒绝策略，不然压力再大都不会抛异常。若能提早观察到线程池队列的积压或线程数量的快速膨胀，每每可提前发现并解决问题。
线程池线程管理
以下方法实现最简陋的监控
自定义个线程池，借助Jodd类库的ThreadFactoryBuilder方法来构造一个线程工厂，实现线程池线程的自定义命名。
而后，咱们写一段测试代码来观察线程池管理线程的策略。测试代码的逻辑为，每次间隔1秒向线程池提交任务，循环20次，每一个任务须要10秒才能执行完成，代码以下：
发现提交失败的记录，日志就像这样
线程池默认行为
不会初始化corePoolSize个线程，有任务来了才建立工做线程 核心线程满后不会当即扩容线程池，而是把任务堆积到工做队列 工做队列满后扩容线程池，直至线程数达到maximumPoolSize 若队列已满且达最大线程后，还有任务来按拒绝策略处理 当线程数大于核心线程数时，线程等待keepAliveTime后仍是无任务须要处理，收缩线程到核心线程数
了解这个策略，有助于咱们根据实际的容量规划需求，为线程池设置合适的初始化参数。也可经过一些手段来改变这些默认工做行为，好比：
声明线程池后当即调用prestartAllCoreThreads方法，来启动全部核心线程 传true给allowCoreThreadTimeOut，让线程池在空闲时一样回收核心线程
Java线程池是先用工做队列来存放来不及处理的任务，满后再扩容线程池。当工做队列设置很大时（那个默认工具类），最大线程数这个参数就没啥意义了，由于队列很难满或到满时可能已OOM，更没机会去扩容线程池了。
是否能让线程池优先开启更多线程，而把队列当成后续方案？
好比案例的任务执行得很慢，须要10s，若线程池可优先扩容到5个最大线程，那么这些任务最终均可以完成，而不会由于线程池扩容过晚致使慢任务来不及处理。
实现思路
实现基本就以下两个难题：
线程池在工做队列满了没法入队的状况下会扩容线程池，那是否可重写队列的offer，人为制造该队列已满的假象？ Hack了队列，在达到最大线程后势必会触发拒绝策略，那么可否实现一个自定义的拒绝策略处理程序，这个时候再把任务真正插入队列？
Tomcat其实已经实现了相似的“弹性”线程池。
务必确认清楚线程池自己是否是复用的
某项目生产环境偶尔报警线程数过多，超过2000个，收到报警后查看监控发现，瞬时线程数比较多但过一下子又会降下来，线程数抖动很厉害，而应用的访问量变化不大。
为定位问题，在线程数较高时抓取线程栈，发现内存中有1000多个自定义线程池。通常来讲，线程池确定是复用的，有5个之内的线程池均可认为正常，但1000多个线程池确定不正常。
在项目代码也没看到声明线程池，搜索execute关键字后定位到，原来是业务代码调用了一个类库来得到线程池，相似以下：
调用ThreadPoolHelper的getThreadPool方法来得到线程池，而后提交数个任务到线程池处理，看不出什么异常。
但getThreadPool方法竟然是每次都使用Executors.newCachedThreadPool来建立一个线程池。
newCachedThreadPool会在须要时建立必要多的线程，业务代码的一次业务操做会向线程池提交多个慢任务，这样执行一次业务操做就会开启多个线程。若是业务操做并发量较大的话，的确有可能一会儿开启几千个线程。
那为何咱们能在监控中看到线程数量会降低，而不OOM？
newCachedThreadPool的核心线程数是0，而keepAliveTime是60s，即60s后全部的线程均可回收。
修复
使用静态字段存放线程池的引用，返回线程池的代码直接返回这个静态字段便可。
考虑线程池的混用
线程池的意义在于复用，那这是否是意味着程序应该始终使用一个线程池？
不是。要根据任务优先级指定线程池的核心参数，包括线程数、回收策略和任务队列。
案例
业务代码使用线程池异步处理一些内存中的数据，但监控发现处理得很慢，整个处理过程都是内存中的计算不涉及I/O操做，也须要数s处理时间，应用程序CPU占用也不是很高。
最终排查发现业务代码使用的线程池，还被一个后台文件批处理任务用了。
模拟一下文件批处理，在程序启动后经过一个线程开启死循环逻辑，不断向线程池提交任务，任务的逻辑是向一个文件中写入大量的数据：
1
能够想象到，这个线程池中的2个线程任务是至关重的。经过printStats方法打印出的日志，咱们观察下线程池的负担：
线程池的2个线程始终处活跃状态，队列也基本满。由于开启了CallerRunsPolicy拒绝处理策略，因此当线程满队列满，任务会在提交任务的线程或调用execute方法的线程执行，也就是说不能认为提交到线程池的任务就必定是异步处理的。
若使用CallerRunsPolicy，有可能异步任务变同步执行。从日志的第四行也能够看到这点。这也是这个拒绝策略比较特别的缘由。
不知道写代码的同窗为何设置这个策略，或许是测试时发现线程池由于任务处理不过来出现了异常，而又不但愿线程池丢弃任务，因此最终选择了这样的拒绝策略。无论怎样，这些日志足以说明线程池饱和了。
业务代码复用这样的线程池来作内存计算就难搞了。
向线程池提交一个简单任务 简单压测TPS为85，性能差
问题没这么简单。原来执行IO任务的线程池使用CallerRunsPolicy，因此直接使用该线程池进行异步计算，当线程池饱和的时候，计算任务会在执行Web请求的Tomcat线程执行，这时就会进一步影响到其余同步处理的线程，甚至形成整个应用程序崩溃。
修正
使用独立的线程池来作这样的“计算任务”。
模拟代码执行的是休眠操做，并不属于CPU绑定的操做，更相似I/O绑定的操做，若线程池线程数设置过小会限制吞吐能力：
使用单独的线程池改造代码后再来测试一下性能，TPS提升到1683
可见盲目复用线程池混用线程的问题在于，别人定义的线程池属性不必定适合你的任务，混用会相互干扰。
就比如，咱们每每会用虚拟化技术来实现资源的隔离，而不是让全部应用程序都直接使用物理机。
线程池混用：Java 8的parallel stream
可方便并行处理集合中的元素，共享同一ForkJoinPool，默认并行度是CPU核数-1。对于CPU绑定的任务，使用这样的配置较合适，但若集合操做涉及同步IO操做的话（好比数据库操做、外部服务调用等），建议自定义一个ForkJoinPool（或普通线程池）。
参考
《阿里巴巴Java开发手册》
公众号-JavaEdge CSDN博客专家 慕课网认证做者 腾讯云+最佳做者 1.经历：19届双一流本科，曾在百度、携程、华为等大厂搬金砖 2.涉猎领域：Java生态各类中间件原理、框架源码、微服务、中台等架构设计及落地实战，只生产硬核干货！ 3.开源社区荣誉：阿里云栖社区博客专家、腾讯云+社区2019年度最佳做者、慕课网认证做者、CSDN百万流量万粉博客专家，简书优秀创做者兼《程序员》专题管理员 4.著做：在牛客网著有《Java源码面试解析指南》，目前已有上千人在学习，已助众多读者成功拿到满意offer~ 关注博主便可阅读全文