事故描述

从 6 点 32 分开始少量用户访问 App 时会出现首页访问异常，到 7 点 20 分首页服务大规模不可用，7 点 36 分问题解决。

整体经过

6:58  发现报警，同时发现群里反馈首页出现网络繁忙，考虑到前几日晚上门店列表服务上线发布过，所以考虑回滚代码紧急处理问题。

7:07 开始先后联系 XXX 查看解决问题。

7:36  代码回滚完，服务恢复正常。

事故根本原因

事故代码模拟：

  public Future<V> take() throws InterruptedException {
        return completionQueue.take();
    }

    public Future<V> poll() {
        return completionQueue.poll();
    }

    public Future<V> poll(long timeout, TimeUnit unit)
            throws InterruptedException {
        return completionQueue.poll(timeout, unit);
    }

所以，业务场景中不需要使用任务返回值的，别没事儿使用 CompletionService。假如使用了，记得一定要从阻塞队列中移除掉 task 执行结果，避免 OOM！

总结

知道事故的原因，我们来总结下方法论。毕竟孔子他老人家说过：自省吾身，常思己过，善修其身！

上线前

• 严格的代码 review 习惯，一定要交给 back 人去看，毕竟自己写的代码自己是看不出问题的，相信每个程序猿都有这个自信；

• 上线记录：备注好上一个可回滚的包版本（给自己留一个后路）；

• 上线前确认回滚后，业务是否可降级。如果不可降级，一定要严格拉长这次上线的监控周期。

上线后

• 持续关注内存增长情况（这部分极容易被忽略，大家对内存的重视度不如 CPU 使用率）；

• 持续关注 CPU 使用率增长情况

• GC 情况、线程数是否增长、是否有频繁的 Full GC 等；

• 关注服务性能报警，TP99、999 、MAX 是否出现明显的增高。

来源：juejin.cn/post/7064376361334358046

最后说一句（别白嫖，求关注）

如果这篇文章对你有所帮助，或者有所启发的话，帮忙点赞、在看、转发、收藏，你的支持就是我坚持下去的最大动力！