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

# 目录

• 事故描述
• 整体经过
• 事故根本原因
• 探讨问题的根源
• 总结

# 事故描述

老规矩，我们先看下事故过程：某日，从 6 点 32 分开始少量用户访问 app 时会出现首页访问异常，到 7 点 20 分首页服务大规模不可用，7 点 36 分问题解决。

# 整体经过

事故的整个经过如下：

• 6：58，发现报警，同时发现群里反馈首页出现网络繁忙，考虑到前几日晚上门店列表服务上线发布过，所以考虑回滚代码紧急处理问题。
• 7：07，开始先后联系 XXX 查看解决问题。
• 7：36，代码回滚完，服务恢复正常。

# 事故根本原因

事故代码模拟如下：

public static void test() throws InterruptedException, ExecutionException {
    Executor executor = Executors.newFixedThreadPool(3);
    CompletionService<String> service = new ExecutorCompletionService<>(executor);
        service.submit(new Callable<String>() {
            @Override
            public String call() throws Exception {
                return "HelloWorld--" + Thread.currentThread().getName();
            }
        });
}

先抛出问题，我们后面会详细阐述。问题的根源就在于 ExecutorCompletionService 结果没调用 take，poll 方法。

正确的写法如下所示：

public static void test() throws InterruptedException, ExecutionException {
    Executor executor = Executors.newFixedThreadPool(3);
    CompletionService<String> service = new ExecutorCompletionService<>(executor);
    service.submit(new Callable<String>() {
        @Override
        public String call() throws Exception {
            return "HelloWorld--" + Thread.currentThread().getName();
        }
    });
    service.take().get();
}

一行代码引发的血案，而且不容易被发现，因为 OOM 是一个内存缓慢增长的过程，稍微粗心大意就会忽略，如果是这个代码块的调用量少的话，很可能几天甚至几个月后暴雷。

操作人回滚 or 重启服务器确实是最快的方式，但是如果不是事后快速分析出 OOM 的代码，而且不巧回滚的版本也是带 OOM 代码的，就比较悲催了。

如刚才所说，流量小了，回滚或者重启都可以释放内存；但是流量大的情况下，除非回滚到正常的版本，否则 GG。

# 探讨问题的根源

接下来我们来探讨问题的根源，为了更好地理解 ExecutorCompletionService 的 “套路”，我们用 ExecutorService 作为对比，可以让我们更好地清楚，什么场景下用 Executo