jacoco引发的血案

终于回归java了！

---

情景复现：109机器复审提交异常，后台报错。

很明显，这是类型转换异常，顺着日志找代码。

显示转换抛了，然后本机调试，没有出现这个问题，顺利通过。又试了下121机器，没有问题。疑惑来了，为什么同样的代码无法复现，只有109有问题？
加日志，观察154行的参数究竟是什么，为什么会报错？

日志信息如下

这个时候还要看看传入的这个obj也就是RuleReqPam这个东西究竟是个啥

看上去也没啥问题，那 “[Z cannot be cast to java.lang.String”这个错误是怎么出现的？？？还是要看日志
最后一个字段信息，即日志中的fields 10的内容有问题。
首先，可以数一下RuleReqPam中字段个数：10个，日志中的fields顺序是for循环的次数，fields 10 显然是有问题的，表示这个参数中有11个字段，为什么？
其次，field 10 的内容：

什么鬼？？？
综上，field 10 肯定是有问题的，哪里冒出来的10呢？还要看日志

可以看到，之前的field的name都是RuleReqPam中的字段，field 10 的 name 却是 $jacocoData，对，它自己高傲的站出来了！就是jacoco！
哪里用jacoco了？pom?看了下，没有，再想想，只有109有这个现象，果断打开jenkins，看！！！

ant?


（感谢百度）
你以为这就结束了？注释掉就可以了？too young，根本没用的，测试大兄弟搞了tomcat

找到原因了，开心不？这就结束了？no！你知道啥是jacoco么？为啥要用jacoco？jacoco是怎么影响到代码执行的？我猜很多人都不知道，当然，我也不知道，所以我学（bai）习（du）了一下，供大家参考。
jacoco是一个代码覆盖率工具，它会在字节码文件中植入统计覆盖率的代码=修改字节码，还记得问题代码不？通过反射进行操作，很显然jacoco很尽职的对这个对象进行了操作，导致程序异常。
惯例，甩链接：https://blog.csdn.net/ohcezzz/article/details/78416125