今天合并主干后，发现在我提交主干前，已有同事提交代码到了主干，当时也没有多想。直接就上线了。上线完一验证，列表页出不来，其他页面也在报网络异常，赶紧回滚。分析线上错误日志，发现dubbo的线程池用完了，其它请求已经有丢失的情况，具体线程耗在哪里当时也着急，没有保留一台实例，就全部回滚了。光从线程已经全部吃掉，初步怀疑为某个服务执行时间过长，一直占着执行线程不放。想到前段时间听别人说有一个接口非常耗时，看了下这个接口的监控时间，平均执行时间都是几十毫秒，只是有时最大执行时间到达了几十秒。这次上线又往这个接口添加异步发消息功能，是不是自己写的代码有问题了？
查看自己的业务代码，把有可能出现问题的地方排查了（抛异常，有问题的地方都记录了日志，查询日志系统也没有打印这个错误日志）。得，明天找架构师和组内高手聊聊，能不能这个方法中的业务搞成异步的。但是一想明天拉着领导和组内高手讨论，但是得先排查掉自己写的代码得没有问题。一想自己在分支上测试没有任务问题，为啥合并到主干，上线后出问题了。从主干上拉个分支，在本地测试下。模拟http请求，调用最耗时的接口，什么情况，http没有应答。打个断点一行一行的执行，执行到某个方法调用的时候，执行不下去了，好像没有跳出这个方法。好吧看看这个方法到底干了啥？尼玛无限for循环，坑死我了，赶紧把写这段代码的高手叫出来，结果人家说线上跑的就是这个代码，但是后来重构了，一看上次上线日期，这高手的代码提交到主干后，一直没上线。问他为什么不测试下再上线了，回了句：我对自己写的代码很有信心。好吧记得以前我上线的时候，也说过，要对自己写的代码要有信心，但那是对业务很熟悉，自己能掌控自己写的代码，到底风险有多大，功能有多大，并且还经过了测试。不知道这高手的信心是从哪里来的。