同事因多线程使用不当导致OOM，被领导怼了一顿

　　目录事故描述整体经过事故根本原因探讨问题的根源总结
　　事故描述
　　老规矩，我们先看下事故过程：某日，从6点32分开始少量用户访问app时会出现首页访问异常，到7点20分首页服务大规模不可用，7点36分问题解决。
　　整体经过
　　事故的整个经过如下：
　　6：58，发现报警，同时发现群里反馈首页出现网络繁忙，考虑到前几日晚上门店列表服务上线发布过，所以考虑回滚代码紧急处理问题。7：07，开始先后联系XXX查看解决问题。7：36，代码回滚完，服务恢复正常。
　　事故根本原因
　　事故代码模拟如下：publicstaticvoidtest（）throwsInterruptedException，ExecutionException｛ExecutorexecutorExecutors。newFixedThreadPool（3）；CompletionServiceStringservicenewExecutorCompletionService（executor）；service。submit（newCallableString（）｛OverridepublicStringcall（）throwsException｛returnHelloWorldThread。currentThread（）。getName（）；｝｝）；｝
　　先抛出问题，我们后面会详细阐述。问题的根源就在于ExecutorCompletionService结果没调用take，poll方法。
　　正确的写法如下所示：publicstaticvoidtest（）throwsInterruptedException，ExecutionException｛ExecutorexecutorExecutors。newFixedThreadPool（3）；CompletionServiceStringservicenewExecutorCompletionService（executor）；service。submit（newCallableString（）｛OverridepublicStringcall（）throwsException｛returnHelloWorldThread。currentThread（）。getName（）；｝｝）；service。take（）。get（）；｝
　　一行代码引发的血案，而且不容易被发现，因为OOM是一个内存缓慢增长的过程，稍微粗心大意就会忽略，如果是这个代码块的调用量少的话，很可能几天甚至几个月后暴雷。
　　操作人回滚or重启服务器确实是最快的方式，但是如果不是事后快速分析出OOM的代码，而且不巧回滚的版本也是带OOM代码的，就比较悲催了。
　　如刚才所说，流量小了，回滚或者重启都可以释放内存；但是流量大的情况下，除非回滚到正常的版本，否则GG。
　　探讨问题的根源
　　接下来我们来探讨问题的根源，为了更好地理解ExecutorCompletionService的套路，我们用ExecutorService作为对比，可以让我们更好地清楚，什么场景下用ExecutorCompletionService。
　　先看ExecutorService代码：（建议down下来跑一跑，以下代码建议吃饭的时候不要去看，味道略重！不过便于理解orz）
　　publicstaticvoidtest1（）throwsException｛ExecutorServiceexecutorServiceExecutors。newCachedThreadPool（）；ArrayListFutureStringfutureArrayListnewArrayList（）；System。out。println（公司让你通知大家聚餐你开车去接人）；FutureStringfuture10executorService。submit（（）｛System。out。println（总裁：我在家上大号我最近拉肚子比较慢要蹲1个小时才能出来你等会来接我吧）；TimeUnit。SECONDS。sleep（10）；System。out。println（总裁：1小时了我上完大号了。你来接吧）；return总裁上完大号了；｝）；futureArrayList。add（future10）；FutureStringfuture3executorService。submit（（）｛System。out。println（研发：我在家上大号我比较快要蹲3分钟就可以出来你等会来接我吧）；TimeUnit。SECONDS。sleep（3）；System。out。println（研发：3分钟我上完大号了。你来接吧）；return研发上完大号了；｝）；futureArrayList。add（future3）；FutureStringfuture6executorService。submit（（）｛System。out。println（中层管理：我在家上大号要蹲10分钟就可以出来你等会来接我吧）；TimeUnit。SECONDS。sleep（6）；System。out。println（中层管理：10分钟我上完大号了。你来接吧）；return中层管理上完大号了；｝）；futureArrayList。add（future6）；TimeUnit。SECONDS。sleep（1）；System。out。println（都通知完了，等着接吧。）；try｛for（FutureStringfuture：futureArrayList）｛StringreturnStrfuture。get（）；System。out。println（returnStr，你去接他）；｝Thread。currentThread（）。join（）；｝catch（Exceptione）｛e。printStackTrace（）；｝｝
　　三个任务，每个任务执行时间分别是10s、3s、6s。
　　通过JDK线程池的submit提交这三个Callable类型的任务：step1：主线程把三个任务提交到线程池里面去，把对应返回的Future放到List里面存起来，然后执行都通知完了，等着接吧。这行输出语句。step2：在循环里面执行future。get（）操作，阻塞等待。最后结果如下：
　　先通知到总裁，也是先接总裁，足足等了1个小时，接到总裁后再去接研发和中层管理，尽管他们早就完事儿了，也得等总裁拉完
　　耗时最久的10s异步任务最先进入list执行，所以在循环过程中获取这个10s的任务结果的时候，get操作会一直阻塞，直到10s异步任务执行完毕。即使3s、5s的任务早就执行完了，也得阻塞等待10s任务执行完。
　　看到这里，尤其是做网关业务的同学可能会产生共鸣，一般来说网关RPC会调用下游N多个接口，如下图：
　　如果都按照ExecutorService这种方式，并且恰巧前几个任务调用的接口耗时比较久，同时阻塞等待，那就比较悲催了。
　　所以ExecutorCompletionService应景而出。它作为任务线程的合理管控者，任务规划师的称号名副其实。相同场景ExecutorCompletionService代码：publicstaticvoidtest2（）throwsException｛ExecutorServiceexecutorServiceExecutors。newCachedThreadPool（）；ExecutorCompletionServiceStringcompletionServicenewExecutorCompletionService（executorService）；System。out。println（公司让你通知大家聚餐你开车去接人）；completionService。submit（（）｛System。out。println（总裁：我在家上大号我最近拉肚子比较慢要蹲1个小时才能出来你等会来接我吧）；TimeUnit。SECONDS。sleep（10）；System。out。println（总裁：1小时了我上完大号了。你来接吧）；return总裁上完大号了；｝）；completionService。submit（（）｛System。out。println（研发：我在家上大号我比较快要蹲3分钟就可以出来你等会来接我吧）；TimeUnit。SECONDS。sleep（3）；System。out。println（研发：3分钟我上完大号了。你来接吧）；return研发上完大号了；｝）；completionService。submit（（）｛System。out。println（中层管理：我在家上大号要蹲10分钟就可以出来你等会来接我吧）；TimeUnit。SECONDS。sleep（6）；System。out。println（中层管理：10分钟我上完大号了。你来接吧）；return中层管理上完大号了；｝）；TimeUnit。SECONDS。sleep（1）；System。out。println（都通知完了，等着接吧。）；提交了3个异步任务）for（inti0；i3；i）｛StringreturnStrcompletionService。take（）。get（）；System。out。println（returnStr，你去接他）；｝Thread。currentThread（）。join（）；｝
　　跑完结果如下：
　　这次就相对高效了一些，虽然先通知的总裁，但是根据大家上大号的速度，谁先拉完先去接谁，不用等待上大号最久的总裁了（现实生活里，建议采用第一种，不等总裁的后果emmm哈哈哈）。
　　放在一起对比下输出结果：
　　两段代码的差异非常小，获取结果的时候ExecutorCompletionService使用了：completionService。take（）。get（）；
　　为毛要用take（）然后再get（）呢？？？？我们看看源码：
　　CompletionService接口以及接口的实现类
　　ExecutorCompletionService是CompletionService接口的实现类：
　　接着跟一下ExecutorCompletionService的构造方法，可以看到入参需要传一个线程池对象，默认使用的队列是LinkedBlockingQueue，不过还有另外一个构造方法可以指定队列类型，如下两张图，两个构造方法。
　　默认LinkedBlockingQueue的构造方法：
　　可选队列类型的构造方法：
　　submit任务提交的两种方式，都是有返回值的，我们例子中用到的就是第一种Callable类型的方法。
　　对比ExecutorService和ExecutorCompletionServicesubmit方法，可以看出区别。
　　ExecutorService：
　　ExecutorCompletionService：
　　差异就在QueueingFuture，这个到底作用是啥？
　　我们继续跟进去看：QueueingFuture继承自FutureTask，而且红线部分标注的位置，重写了done（）方法。把task放到completionQueue队列里面，当任务执行完成后，task就会被放到队列里面去了。此时此刻completionQueue队列里面的task都是已经done（）完成了的task，而这个task就是我们拿到的一个个的future结果。如果调用completionQueue的task方法，会阻塞等待任务。等到的一定是完成了的future，我们调用。get（）方法就能立马获得结果。
　　看到这里，相信大家伙都应该多少明白点了：
　　我们在使用ExecutorServicesubmit提交任务后需要关注每个任务返回的future，然而CompletionService对这些future进行了追踪，并且重写了done方法，让你等的CompletionQueue队列里面一定是完成了的task。作为网关RPC层，我们不用因为某一个接口的响应慢拖累所有的请求，可以在处理最快响应的业务场景里使用CompletionService。
　　but，注意、注意、注意，也是本次事故的核心
　　当只有调用了ExecutorCompletionService下面的3个方法的任意一个时，阻塞队列中的task执行结果才会从队列中移除掉，释放堆内存。
　　由于该业务不需要使用任务的返回值，则没进行调用take，poll方法。从而导致没有释放堆内存，堆内存会随着调用量的增加一直增长。
　　所以，业务场景中不需要使用任务返回值的别没事儿使用CompletionService，假如使用了，记得一定要从阻塞队列中移除掉task执行结果，避免OOM！
　　总结
　　知道事故的原因，我们来总结下方法论，毕竟孔子他老人家说过：自省吾身，常思己过，善修其身！
　　上线前：
　　严格的代码review习惯，一定要交给back人去看，毕竟自己写的代码自己是看不出问题的，相信每个程序猿都有这个自信（这个后续事故里可能会反复提到，很重要）上线记录备注好上一个可回滚的包版本（给自己留一个后路）上线前确认回滚后，业务是否可降级，如果不可降级，一定要严格拉长这次上线的监控周期
　　上线后：持续关注内存增长情况（这部分极容易被忽略，大家对内存的重视度不如CPU使用率）持续关注CPU使用率增长情况GC情况、线程数是否增长、是否有频繁的FullGC等关注服务性能报警，tp99、999、max是否出现明显的增高
　　来源：https：juejin。cnpost7064376361334358046