一个毕生难忘的BUG

记得之前接手过一个Java项目，服务器程序，直接让Jar在linux上跑的那种，

 

这个项目由两个web服务组成，也就是两条Java进程，主进程 xxx.jar，辅助进程 xxx_helper.jar。主进程程序中某些功能依赖于辅助进程提供的服务。

 

困扰咱们的BUG是在生产环境中辅助进程xxx_helpler.jar不定时无端崩溃，且无jvm错误日志产生，也无被系统自己由于资源损耗严重问题而杀死的记录。 百思不得其解之下咱们只能把问题归因因而程序存在性能问题而被杀死，至于为何没有杀死记录没人知道。 当时团队中没有linux玩的很溜的人，也不会查记录，经过咱们那点粗浅的经验，咱们想固然的觉得程序崩溃就是由于消耗内存过多被系统杀死的，由于当时跑这个程序的机器内存异常紧张，全部人的思路都往这个方向被带了过去。

 

我开始优化xxx_helper.jar程序的性能，什么缓存、多线程、jvm启动参数调优、下降代码算法事件复杂的，反正各类折腾，几乎把代码所有重写一遍， 可程序无辜崩溃问题依旧存在 。

 

为了这个问题我连着好多天吃很差睡不香，作梦都在想办法解决这个问题。 写代码多年，这个问题让我体验到史无前例的无力感。 然而，正当我机关用尽之际， 起色来了。 我无心间打开了重启主进程xxx.jar的脚本，发现里面有这么一段

 

ps aux | grep xxx | awk  '{print $2}' | xargs kill -9

 

这段脚本的做用是，提取进程名称中有xxx关键字的进程ID， 而后kill之。由于整个脚本的逻辑是先关闭存在的进程，而后再启动。

 

而个人项目主进程xxx.jar和辅助进程xxx_helper.jar名称中都存在xxx关键字， 也就是说以前xxx_helper.jar这个进程无辜崩溃并非由于程序自己的缘由，而是由于主进程启动脚本在杀死主进程xxx.jar时一道把xxx_helper.jar也给杀了。

 

看到这段脚本我整我的呆了，就由于一时疏忽，却浪费了好几天的时间， 这跟花了几千块钱买到价值几块钱的东西是同样的感觉，并且我这仍是本身坑本身，这种滋味别提有多难受了。 我当时就用38码的手狠狠的抽打本身40码的脸，以发泄心里悔恨自责的情绪。

 

后来，等冷静下来之后，我只能安慰本身花了这么多功夫也不是一无所得，至少程序的性能是被我实实在在优化了。 虽然， 这种优化对于这个项目是毫无心义的。

 

经过这个事故我领悟到，对于某些顽固的程序BUG，当咱们根据本身想固然的经验难以找到造成缘由时， 就应该跳出问题的自己或者本身寻找BUG的思惟框架来思考， 由于形成BUG的缘由每每和以前寻找BUG的路径八竿子打不着。