年年出妖事，一例由JSON解析导致的“薛定谔BUG“排查过程记录

前言

做开发这么多年，也碰到无数的bug了。不过再复杂的bug，只要仔细去研读代码，加上debug，总能找到原因。

但是最近公司内碰到的这一个bug，这个bug初看很简单，但是非常妖孽，在一段时间内我甚至是百思不得其解。在长达几天的时间内，复现的概率非常低。几乎难以抓住任何踪迹。

所以这篇文章就非常写实的来记录一下此Bug的发现和排查整个过程。

起因

同事之前做了个需求，提交测试。测试同事在测的一半的时候。发现了后台的一个报错

com.alibaba.fastjson.JSONException: can not cast to String, value : {"code":"00","msg":"成功","data":{这里是正确的数据}}
 at com.alibaba.fastjson.util.TypeUtils.castToInt(TypeUtils.java:564) ~[fastjson-1.2.29.jar:na]
 at com.alibaba.fastjson.serializer.IntegerCodec.deserialze(IntegerCodec.java:89) ~[fastjson-1.2.29.jar:na]

一看就知道这错很简单，就是一个fastjson的转换类型的报错。接受的json和要转化的类型不匹配造成的。基本上检查下代码，一眼就能解决的。

结果同事看了好一会儿，都没发现哪有问题。

然后远程在测试环境debug运行，打上断点准备调试，测试同事操作下来，却又好了。

然后释放断点，正常运行。操作一会，又出现了相同报错。

继续打上断点，还是正常。

这个现象把同事整的有点懵，我在群里看到这个，觉得这个现象很有趣，结果竟然依赖于是否观测，这什么鬼。。

我接过手看了下代码，我初步看下来也是完全没问题的。

代码我经过了精简和一些伪代码处理，如下所示：

public <T> T executeLua(String luaName, Class<T> c, Object... args){
 String json = 执行器.执行(luaName，args);
  log.info("执行结果为:{}",json);
  T resut = JSON.parseObject(json