记得以前接手过一个 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 的路径八竿子打不着
来源: https://www.cnblogs.com/aspwebchh/p/8706250.html