背景
在交代的代码中做四肢进行删库等操作，之前仅仅网上传闻的段子，没想到上周还真遇到了，而且亲自参与帮助处理。
工作是这样的，一老板接手了一套体系，或许因为两边在交代时出现了什么不愉快的工作，对方不供给源代码，仅仅把出产环境的服务器打了一个镜像给到对方。
对方拿到镜像恢复之后，体系起来怎么也无法正常处理事务，所以就找到我帮助看是什么原因。通过排查，本来交代的人在镜像中做了多处四肢，多处删去中心数据及jar包操作。下面来给我们细细分析排查进程。
排查进程
因为只供给了镜像文件，导致究竟发动哪些服务都是问题。好在是Linux操作体系，镜像恢复之后，通过history指令可以检查从前履行了哪些指令，可以找到都需求发动哪些服务。但服务发动之后，事务无法正常处理，许多事务都处于中心态。
本来体系是可以正常跑事务的，打个镜像之后再恢复就不可以了？这就奇怪了。所以对项目（jar包或war）文件进行排查，检查它们的修正时刻。
在文件的修正时刻上还真找到了一些问题，发现在打镜像的两个小时前，项目中一个多个项目底层依靠的jar包被修正过，另外还有两个class文件被修正过。
所以，就对它们进行了重点排查。首先反编译了那两个被修正过的class文件，在代码中找到了可疑的当地。
在两个被修正的类中都有上述代码。最开始没太留意这段代码，但直觉告诉我不太对，一个查询事务里面怎么或许出现删去操作呢？这太不契合常理了。
所以仔细阅读上述代码，发现上述红框中的代码不管何时履行终究的成果都是id=1。你是否看出来了？问题就出在三目表达式上，不管id是否为null，id被赋的值都是1。看到这儿，也慨叹对方是用心了。为了隐藏这个意图，前面写了那么多无用的代码。
但只要这个还不是什么问题，毕竟如果仅仅删去id为1的值，也仅仅删去了一条记录，影响范围应该有限。
紧接着反编译了被修正的jar包，依次去找上述删去办法的底层完成，看到如下代码：
本来前面传递的id=1是为了合作where条件句子啊，当id=1被传递进来之后，就形成了where 1=1的条件句子。这个我们在mybatis中拼接多条件句子时经常用到。成果就是一旦履行了上述事务逻辑，就会触发删去T_QUART_DATA全表数据的操作。
而T_QUART_DATA表中是用于存储触发守时使命的表达式，到这儿也就理解了，为啥前面的事务跑不起来，悉数是中心态了。因为一旦在事务逻辑中触发开关，把守时使命的cron表达式悉数删去，十多个守时使命悉数歇菜，事务也就跑步起来了。
找到了问题的本源，处理起来就不是啥事了，因为没有源代码，稍微费力的是只能把原项目整个反编译出来，然后将改修正当地进行了修正。
又起波折
本认为到此问题现已处理结束了，没想到第二天又出现问题了，项目又跑不起来了。通过多方排查和定位，感觉还有守时使命再进行暗箱操作。
所以通过Linux的crontab指令检查是否有守时使命在履行，履行crontab -e或crontab -l，还真看到有三个守时使命在履行。跟踪到守时使命履行的脚本中，而且明目张胆的起名deleteXXX：
而在具体的脚本中，有如下履行操作：
这下找到为什么项目中第二天为啥跑不起来了，本来Linux的守时使命将中心依靠包删去了，而且还会去重启服务。
为了搞破坏，真是煞费苦心啊。还好的是这个jar包在前一天现已反编译出来了，也算有了备份。
小结
本来认为程序员在代码中进行删库操作或做一些其他小四肢仅仅网络上的段子，大多数人出于职业操行或个人质量是不会做的。没想到这还真遇到了，而且对方为了隐藏删去操作，还做了一些小假装，真的是煞费苦心啊。如果有这样的能力和心思，用在写出更优秀的代码或体系上或许更好。
当然，不知道他们在交代的进程中究竟发生了什么，竟然用这样的方法对待昔日合作的伙伴。之所以写这篇文章，是想让我们学习如何排查代码问题的进程，毕竟用到了不少知识点和技能，但这并不是教我们如何去做四肢。不管怎样，最起码的职业操行还是要有的，这点不接受辩驳。
