一个毕生难忘的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的路径八竿子打不着。