#目录
事故描述整体经过事故根本原因探讨问题的根源总结
#事故描述
老规矩，我们先看下事故过程：某日，从6点32分开始少量用户访问app时会出现首页访问异常，到7点20分首页服务大规模不可用，7点36分问题解决。
#整体经过
事故的整个经过如下：
6：58，发现报警，同时发现群里反馈首页出现网络繁忙，考虑到前几日晚上门店列表服务上线发布过，所以考虑回滚代码紧急处理问题。7：07，开始先后联系XXX查看解决问题。7：36，代码回滚完，服务恢复正常。
#事故根本原因
事故代码模拟如下：
publicstaticvoidtest()throwsInterruptedException,ExecutionException{Executorexecutor=Executors.newFixedThadPool(3);CompletionServiceStringservice=newExecutorCompletionService(executor);service.submit(newCallableString(){
OverridepublicStringcall()throwsException{turn"HelloWorld--"+Thad.curntThad().getName();}});}先抛出问题，我们后面会详细阐述。问题的根源就在于ExecutorCompletionService结果没调用take，poll方法。
正确的写法如下所示：
publicstaticvoidtest()throwsInterruptedException,ExecutionException{Executorexecutor=Executors.newFixedThadPool(3);CompletionServiceStringservice=newExecutorCompletionService(executor);service.submit(newCallableString(){
OverridepublicStringcall()throwsException{turn"HelloWorld--"+Thad.curntThad().getName();}});service.take().get();}一行代码引发的血案，而且不容易被发现，因为OOM是一个内存缓慢增长的过程，稍微粗心大意就会忽略，如果是这个代码块的调用量少的话，很可能几天甚至几个月后暴雷。
操作人回滚or重启服务器确实是最快的方式，但是如果不是事后快速分析出OOM的代码，而且不巧回滚的版本也是带OOM代码的，就比较悲催了。
如刚才所说，流量小了，回滚或者重启都可以释放内存；但是流量大的情况下，除非回滚到正常的版本，否则GG。
#探讨问题的根源
接下来我们来探讨问题的根源，为了更好地理解ExecutorCompletionService的“套路”，我们用ExecutorService作为对比，可以让我们更好地清楚，什么场景下用ExecutorCompletionService。
先看ExecutorService代码：（建议down下来跑一跑，以下代码建议吃饭的时候不要去看，味道略重！不过便于理解orz）
publicstaticvoidtest1()throwsException{ExecutorServiceexecutorService=Executors.newCachedThadPool();ArrayListFutuStringfutuArrayList=newArrayList();System.out.println("公司让你通知大家聚餐你开车去接人");FutuStringfutu10=executorService.submit(()-{System.out.println("总裁：我在家上大号我最近拉肚子比较慢要蹲1个小时才能出来你等会来接我吧");TimeUnit.SECONDS.sleep(10);System.out.println("总裁：1小时了我上完大号了。你来接吧");turn"总裁上完大号了";});futuArrayList.add(futu10);FutuStringfutu3=executorService.submit(()-{System.out.println("研发：我在家上大号我比较快要蹲3分钟就可以出来你等会来接我吧");TimeUnit.SECONDS.sleep(3);System.out.println("研发：3分钟我上完大号了。你来接吧");turn"研发上完大号了";});futuArrayList.add(futu3);FutuStringfutu6=executorService.submit(()-{System.out.println("中层管理：我在家上大号要蹲10分钟就可以出来你等会来接我吧");TimeUnit.SECONDS.sleep(6);System.out.println("中层管理：10分钟我上完大号了。你来接吧");turn"中层管理上完大号了";});futuArrayList.add(futu6);TimeUnit.SECONDS.sleep(1);System.out.println("都通知完了,等着接吧。");try{for(FutuStringfutu:futuArrayList){StringturnStr=futu.get();System.out.println(turnStr+"，你去接他");}Thad.curntThad().join();}catch(Exceptione){e.printStackTrace();}}
三个任务，每个任务执行时间分别是10s、3s、6s。
通过JDK线程池的submit提交这三个Callable类型的任务：
step1：主线程把三个任务提交到线程池里面去，把对应返回的Futu放到List里面存起来，然后执行“都通知完了，等着接吧。”这行输出语句。step2：在循环里面执行futu.get()操作，阻塞等待。
最后结果如下：
先通知到总裁，也是先接总裁，足足等了1个小时，接到总裁后再去接研发和中层管理，尽管他们早就完事儿了，也得等总裁拉完~~
耗时最久的-10s异步任务最先进入list执行，所以在循环过程中获取这个10s的任务结果的时候，get操作会一直阻塞，直到10s异步任务执行完毕。即使3s、5s的任务早就执行完了，也得阻塞等待10s任务执行完。
看到这里，尤其是做网关业务的同学可能会产生共鸣，一般来说网关RPC会调用下游N多个接口，如下图：
如果都按照ExecutorService这种方式，并且恰巧前几个任务调用的接口耗时比较久，同时阻塞等待，那就比较悲催了。
所以ExecutorCompletionService应景而出。它作为任务线程的合理管控者，“任务规划师”的称号名副其实。
相同场景ExecutorCompletionService代码：
publicstaticvoidtest2()throwsException{ExecutorServiceexecutorService=Executors.newCachedThadPool();ExecutorCompletionServiceString
转载请注明：http://www.0431gb208.com/sjszjzl/2231.html
