服务器故障实例分析

1. 出故障了

由于从事IT这个行业，我们需要每天应对故障和问题，因此我们可以称之为消防员，处处奔波解决问题。不过，这次的故障范围有点大，宿主机都打不开了。

好在监控系统留下了一些证据。

证据发现，机器的CPU、内存、文件句柄，随着业务的增长，持续的上升...上升....，直到监控也无法将信息收集上来。

要命的是，这些宿主机上，部署了非常多的Java进程。没别的原因，就是为了节省成本，混部了应用。当宿主机表现出整体性的异常时，就难以找到罪魁祸首。

由于遥控登录已失效，急躁的运维人员只能选择重启机器，并在重新启动后开始重启应用程序。经过漫长的等待，所有进程都恢复正常运行，但是仅仅过了短暂的时间，宿主机就突然宕机了。

业务一直处于死翘翘的状态，真是让人恼火啊。也让人心急。尝试过几次之后，运维崩溃了，启动了紧急预案：回滚!

最近的上线记录有点多，而且有开发人员私自上线部署的行为，运维蒙圈了：回滚哪些呢?还好有人脑瓜一亮，想起了还有find这个命令，那就找到最近更新的所有jar包，都给它来次回滚吧。

find /apps/deploy -mtime +3 | grep jar$

如果你不知道find这个命令，那可还真的是一场灾难。还好有人知道。

把十来个jar包回滚，还好没有碰到数据库的schema变更，系统终于正常运行了。

2. 找原因

没别的办法，查日志，进行代码审查。

为了确保代码的质量，代码审查的范围应该限定在最近1周或2周内的代码改动，因为一些功能代码需要一定时间的沉淀，才能在线上独放异彩。

看着满屏的提交记录“OK”，技术经理的脸都绿了。

“xjjdog说过，《80%的程序员，不会写commit记录》，我看你们是100%都不会写”。

大家都静悄悄的，忍着痛翻查历史变更。经过大家的不懈努力，终于在屎山之间，找到了一些问题代码。一个CxO亲自创建的群，大家纷纷将可能出现问题的代码扔进去。

"系统服务中断了接近一个小时，影响非常恶劣"，CxO说，“务必把问题彻底解决掉，这个问题投资人非常关注”!

okokok，有了钉钉的助力，大家的手势都变得整齐划一。

3. 线程池的参数

代码有点多，大家对问题代码讨论了老久。这句话的重写如下： 我们检查了一些使用并行流和嵌套在lambda表达式中的复杂代码，并在其中特别关注了线程池的使用。

最后大家决定还是对线程池的代码再过一遍。其中有一段是这么写的。

RejectedExecutionHandler handler = new ThreadPoolExecutor.DiscardOldestPolicy(); ThreadPoolExecutor executor = new ThreadPoolExecutor(100,200,                 60000,                 TimeUnit.MILLISECONDS,                 new LinkedBlockingDeque<>(10),                 handler);

还别说，参数有模有样的，甚至考虑到了拒绝策略。

Java的线程池，使得编程变的非常简单。如果不逐一介绍，这些参数就无法被审查，如上图所示。

• corePoolSize：核心线程数，核心线程创建后会一直存活

• maxPoolSize：最大线程数

• keepAliveTime：线程空闲时间

• workQueue：阻塞队列

• threadFactory：线程创建工厂

• handler：拒绝策略

下面来介绍一下它们的关系。

如果线程数少于核心线程数时，有新任务到来，系统会创建一个新线程来处理该任务。如果当前线程数量超过核心线程数量，且阻塞队列未满，任务将被放入阻塞队列中。当线程数大于核心线程数，而且阻塞队列满了的时候，将会创建新的线程进行服务，直到线程数到达maximumPoolSize的大小。此时，如果还有新的任务，将触发拒绝策略。

再说一下拒绝策略。JDK内置了4种策略，其中默认的是AbortPolicy，即直接抛出异常。下面介绍其他几种。

• DiscardPolicy 比abort更加激进，直接丢掉任务，连异常信息都没有

• 任务处理是由调用线程执行的，这是 CallerRunsPolicy 的实现方式。当一个Web应用的线程池资源被占满后，新增的任务会被分配到Tomcat线程中执行。在某些情况下，这种方法可以减轻一些任务的执行压力，但在更多情况下，它会直接阻塞主线程的运行

• DiscardOldestPolicy 丢弃队列最前面的任务，然后重新尝试执行任务

这段线程池代码是新添加的，参数设置也比较合理，没有太大的问题。使用DiscardOldestPolicy拒绝策略是唯一可能存在的风险。当任务非常多的时候，这个拒绝策略会造成任务排队，请求超时。

当然不能放过这种风险，说实话也是到现在为之能够找到的最可能的风险代码了。

"把DiscardOldestPolicy 改成默认的AbortPolicy吧，重新打包上线一下试试“。技术大牛在群里说。

4. 问题在哪里?

结果，服务灰度上线之后，宿主机不多时，就死掉了。是它的原因没跑了，但是why?

线程池的大小 ，最小100，最大200，说什么也不过分。阻塞队列的容量只有10，说什么也不会造成问题。你要说是这个线程池造成的原因，打死我都不信。

但是业务部门反馈，这段代码加上就死，不加就没事。技术大牛们抓耳挠腮百思不得其姐。

到最后，终于有人忍不住了，下载下业务的代码打算调试一下。

当他打开Idea的时候，瞬间懵逼了，又瞬间领悟了。他终于明白了这段代码为什么会产生问题了。

线程池，竟然是在方法里创建的!

当每一个请求到来的时候，它都会创建一个线程池，直到系统再也无法分配资源为止。

可真是霸道啊。

所有人都在关注线程池的参数是怎么设置的，但从来没有人怀疑这段代码所在的位置。

以上就是服务器故障实例分析的详细内容，更多请关注其它相关文章！