场景再现：
"今天发版的文档都准备好了吗？"组长问道。
"组长，全都准备好了，代码也提交了，你合并一下pro分支吧"小猿回答道。
"好。我合并过了，等会发完版自己观察一下你的新功能，要敬畏生产，敬畏发版，一切都要细心，确保万无一失"组长娓娓道来。
"好，知道了"小猿回答道。
发版完毕。功能都验证了，没啥问题。"组长，我验证了，没问题"小猿给组长汇报了基本情况。
突然，钉钉群报警开始，xxx项目内存使用超过70%请注意！内存使用超过80%请注意！内存使用超过90%请注意！
......接下来，报警更严重了xx项目已经下线.....组长电话响了"你们干什么了，系统蹦了，赶快处理，别影响业务，给你5分钟，给我处理完毕"，领导气哄哄的说到。
此时的小猿，内心慌的一逼，因为今天只有他上线了一个功能......
一、线上业务必须快速能用啊，咋办？
别慌，很简单。
回滚啊，1分钟时间就把今天发版的项目回滚到了上一个版本，系统又正常使用了。
线上问题处理必须要快，哪怕新功能先延迟上线呢，也不能让线上已经有的业务不能用啊。具体问题的根源肯定是下来之后慢慢排查了。
二、开始排查具体原因了
- 因为是新上线的功能，所以基本上可以缩小了排查的范围了
- 通过skywalking日志工具，直接搜索最近刚才系统异常的时间段+刚发布的服务看到了出现了oom的异常（系统都宕机了，一般都是内存溢出了）
- 下载具体的日志，看到了xxxserver.java(134)然后直接去排查具体行数代码，发现这里手动开启了一个多线程，每个线程都是单独处理这次刚上线的业务逻辑，检查了逻辑没啥大问题。但是，开启线程关闭的时候，直接业务处理完毕，就在下面调用了close()方法，但是，好巧不巧，真实业务由于某种原因，每次到某类型的时候，由于数据不存在，异常了.....后面逻辑没有走，开启的线程就一一直没有关闭。
三、解决问题
这里要注意了啊，尤其是工作经验不多的同学，一定一定要多思考，或者把写完的代码让ai帮你检查一下，不要太自信了，感觉功能上线了就行了。
解决方案：使用try catch finally 在finally关闭开启的线程。
简单吧，但是的确发生了，这位新同学对这次事故一定很难忘吧！
总结、敬畏生产
我们做开发一定要敬畏生产环境，要多思考，自测充分，很多时候线上问题都是因为很小的问题造成的。