原因是最近推出了一个版本，要求对敏感内容进行过滤。半夜上线的时候，一切正常，但是……第二天中午，突然报警，并在线反馈相关问题。函数有问题。查看elk日志，相关接口耗时较多，部分连接超时（包括redismysql和一些外部http请求。系统响应很慢，一般是几毫秒或者十几毫秒的接口，突然就出来了变得异常缓慢）本来是午休午休，看到这些问题，我瞬间清醒过来，吓得浑身发抖。查清楚了，这次查的是在线的，所以没有直接dump线程文件什么的，而是先看日志和监控盘。可以说监控刻度盘已经很明显了。由于事后诸葛亮，这里贴几张当时截取的图片，象征性的看一下。看监控dashboard检测系统各种指标cputcp相关状态图：文件描述符相关监控图：内存和线程状态图：一些解释：首先，当时上线后，问题并没有立即出现，说明系统运行了一段时间“积累”，其实很多连接cpu或者关于gc的问题都会这样，会有一个积累的过程，直到达到某个点或者某个范围，效果开始显现！！从上面三张图可以看出文件描述符使用率很高，timed_waiting线程很多，cpu内存也不正常。有些异常可能是由于某些异常因素的间接影响而引起的。总之，我们知道系统存在没错。7月9日中午左右，我们重启服务，发现异常现象如：文件描述符、cpu、线程，tcp的一些异常指标直接掉线。然后在10日凌晨发布了bugfix版本，分析了elk中相关功能的日志。由于读取日志涉及隐私，当时并没有截取内容，所以这里就不贴图了。简单文字说明：大致逻辑如下：1：获取待检测内容->2：（使用腾讯sdk）构建调用对象（cosClient）->3：调用腾讯敏感检测相关接口->4：返回。通过观察日志，发现（2）的时间比较长，占了整个界面的90%以上，于是赶紧看了一下这块的代码。代码很简单，就是构建cosCleint对象调用相应的api（sdk形式调用），我一步步跟着看，发现里面已经做了很多工作。由于时间原因没有调试具体的细节，于是把希望寄托在了腾讯的文档上。在打开文档的时候无意中发现了这样一段描述：解决发现的问题。看完这一段，终于明白哪里出了问题，赶紧把每次新的调用对象都改成单例（卧槽。。。。。没想到是因为这个疏忽。。。正应了那句话：荆州粗心！没想到会在这方面被绊倒）在bugfix版本中，我将新建对象改成如下代码：Singleton.get(XXX.class,yyy,zzz);发布后问题得到解决。回家睡觉吧！总结通过这次上网事故，让我明白了四点：记录日志，监控系统，打印准确有效的日志是多么的重要！系统上线后，必须有一个观察期。不能说当时验收没有问题就万事大吉了。对于与外界连接的东西，一定要仔细阅读对接或接口文档，确保没有遗漏。敬畏每一行代码，思考每一行代码！！！
