fastjson的这些坑，你误入了没？

背景：最近 fastjson 被爆出新的远程代码执行漏洞之后，赶紧督促项目组快马加鞭去修改（吐槽：真改不动，架不住项目既多又老），鉴于项目不同，依赖的 fastjson 版本也不同，本次着重谈 fastjson 1.2.16 版本遇到的那些问题？1

1

兼容性：低版本没问题，高版本抛异常 

一、抛问题。

摘取部分代码片段，稍加改造如下。

import com.alibaba.fastjson.JSONArray;
import com.alibaba.fastjson.JSONObject;


import java.util.ArrayList;
import java.util.HashMap;
import java.util.List;
import java.util.Map;


/**
 * fastjson 坑啊！
 *
 * @author 一猿小讲
 */
public class T {
    public static void main(String[] args) {
        JSONObject retJson = new JSONObject();
        retJson.put("retCode", "0000");
        retJson.put("retMsg", "Pay Succ");


        List> retList = new ArrayList>();
        Map retMap = new HashMap();
        retMap.put("orderId", "O010000088888");
        retMap.put("payerName", "张三");
        retList.add(retMap);


        retJson.put("retList", retList);


        if (retJson.containsKey("retList")) {
            JSONArray jsonArray = retJson.getJSONArray("retList");
            for (Object object : jsonArray) {
                JSONObject orderObject = (JSONObject) object;
                System.out.println("假装要执行的处理===>" + orderObject);
            }
        }
    }
}

引入依赖（低版本）：

    com.alibaba
    fastjson
    1.2.16

代码跑起来（真爽，飞一般的感觉）：

假装要执行的处理===>{"orderId":"O010000088888","payerName":"张三"}

此时，把 fastjson 升级成高版本：

    com.alibaba
    fastjson
    1.2.70

代码跑起来（浪奔浪流，万里涛涛泪水永不休）：

Exception in thread "main" java.lang.ClassCastException: java.util.HashMap cannot be cast to com.alibaba.fastjson.JSONObject
  at T.main(T.java:31)

很明显，第 31 行代码抛出了异常

JSONObject orderObject = (JSONObject) object;

而且很明确：java.util.HashMap不能转换成com.alibaba.fastjson.JSONObject。

二、1.2.16 版本没问题，升级到 1.2.70 就抛异常，敢问这是为什么？

分析一：fastjson 1.2.16 版本下捉虫子。

分析二：fastjson 1.2.70 版本下捉虫子。

版本 1.2.16 vs 版本 1.2.70：

• 两幅图的标注 1 对比着看，会发现低版本的 JSONArray 中存进去的是 JSONObject，而高版本的存进去的是 HashMap；

• 两幅图的标注 2 对比着看，会发现低版本中 JSONObject 强转成 JSONObject，当然没问题，而高版本拿 HashMap 强转成 JSONObject 就会出现 ClassCastException。

到这儿，感觉还不是很解气，势必要打破砂锅刨到底！

版本 1.2.16 的源码刨到底：

而顺着版本 1.2.16 的源码一路看到底，会发现会对 Map 进行二次封装处理，最终会包装成 JSONObject 对象（这或许就是能强转成 JSONObject 的原因，存进去的是牛，强转成牛，当然没问题）。

版本 1.2.70 的源码刨到底：

版本 1.2.70 vs 版本 1.2.16，很显然 1.2.70 版本增加了一个集合的条件分支判断，如果根据 key 获取的 value 是 List，则会构建 JSONArray 对象，如下面源码截图示意，List 里面的值不会做变化，如果 List 中放入的是 Map，则不会对 Map 进行二次处理（这可能就是强制转换成 JSONObect 失败的原因，存进去的是牛，非要强转成马，当然行不通）。

三、该怎么解决版本升级，带来的兼容性问题呢？

很简单，既然高版本的没有对 list 中的 Object 进行转换，咱们就刻意调用 toJSON 方法进行转换一番。

retJson.put("retList", retList);
修改为
retJson.put("retList", JSON.toJSON(retList));

代码跑起来，Debug 看看效果如何：

很明显，JSONArray 中获取的 object 类型已变为 JSONObject，当然在 1.2.16、1.2.70 版本跑起来都畅通无阻，那么版本升级带来的问题就迎刃而解。

四、闲扯淡（走心）

• 写代码时候还是需要注意点，能稍微规范些，就尽量按照规范，就如本次提到的问题，向 JSONObject 中加入 List 时，不妨先提前 toJSON 转换一番，这样版本升级也不会有问题。

• 由于依赖包升级导致不兼容的情况很常见，不过绝大多数都是向下兼容的，例如 JDK ... 5、6、7、8 ...，所以如果你正在开发核心代码，若涉及到版本更新，尽量考虑兼容性问题，如果涉及到老功能废弃时，不妨采用注解标注一下，这样后人会尽早发现问题。

2

 不规范的传入：导致内存溢出  

分享一段有意思的代码，一起享受其中乐趣。

import com.alibaba.fastjson.JSON;
/**
 * fastjson 坑啊！
 * @author 一猿小讲
 */
public class T {
    public static void main(String[] args) {
        String str = "{\"key1\":\"\\value1\"}";
        Object obj = JSON.parse(str);
        System.out.println(obj);
    }
}

代码能跑起来，运行结果绝对正常

{"key1":"\u000Balue1"}

此时，我们动点手脚，把 value1 的值变掉

String str = "{\"key1\":\"\\x";

程序运行，word 天，惊呆！

Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
  at com.alibaba.fastjson.parser.JSONLexerBase.putChar(JSONLexerBase.java:2835)
  at com.alibaba.fastjson.parser.JSONLexerBase.scanString(JSONLexerBase.java:866)
  at com.alibaba.fastjson.parser.DefaultJSONParser.parseObject(DefaultJSONParser.java:428)
  at com.alibaba.fastjson.parser.DefaultJSONParser.parse(DefaultJSONParser.java:1302)
  at com.alibaba.fastjson.parser.DefaultJSONParser.parse(DefaultJSONParser.java:1268)
  at com.alibaba.fastjson.JSON.parse(JSON.java:137)
  at com.alibaba.fastjson.JSON.parse(JSON.java:128)
  at T.main(T.java:11)

好奇不？咋回事？Debug 分析一番就清楚啦。

当 json 字符串是以 \x 结尾时，由于低版本的 fastjson 并未对其进行校验，将会导致其继续尝试获取字符。

由于 index>= this.len 始终成立，则意味着会直接获取到 \u001A，相当于 26，带来的结果就是 isEOF 永远为 false，意味着要无休止的读下去。

就这样陷入了死循环 1-->2-->3-->1，直到内存溢出。

Debug 一趟肯定比我说的要清楚，当然，此问题早已在版本 1.2.60 中修复。

1.2.70 版本肯定也不会有此问题啦，在高版本下直接提示格式错误啦，摆脱了内存异常。

Exception in thread "main" com.alibaba.fastjson.JSONException: invalid escape character \x
  at com.alibaba.fastjson.parser.JSONLexerBase.scanString(JSONLexerBase.java:984)
  at com.alibaba.fastjson.parser.DefaultJSONParser.parseObject(DefaultJSONParser.java:479)
  at com.alibaba.fastjson.parser.DefaultJSONParser.parse(DefaultJSONParser.java:1401)
  at com.alibaba.fastjson.parser.DefaultJSONParser.parse(DefaultJSONParser.java:1367)
  at com.alibaba.fastjson.JSON.parse(JSON.java:183)
  at com.alibaba.fastjson.JSON.parse(JSON.java:193)
  at com.alibaba.fastjson.JSON.parse(JSON.java:149)
  at T.main(T.java:11)

走心：

• 金无足赤人无完人，代码有 Bug 很正常，需要一步一步去迭代，要敢于让团队犯错、试错、容错。

• 通过此段测试，项目开发中参数格式校验就很有必要。

3

寄语写最后

本次，仅以项目中依赖 fastjson 类库作为切入点，主要想传达：在使用三方轮子时，尽可能做对三方的轮子了如之掌，知己知彼方能百战不殆。

另外，借助 fastjson 升级的事情，也想传达写出规范性的代码，是很有必要，不然升级的时候就很麻烦。代码修炼系列分享，仍会结合实际项目进行继续分享，请各位持续关注。

（一）改掉这些坏习惯，还怕写不出健壮的代码？

（二）改掉这些坏习惯，还怕写不出优雅的代码？

（三）改掉这些坏习惯，还怕写不出优雅的代码？

（四）改掉这些坏习惯，还怕写不出健壮的代码？

（五）改掉这些坏习惯，还怕写不出精简的代码？

（六）改掉这些坏习惯，还怕写不出精简的代码？

好了，本次就谈到这里，一起聊技术、谈业务、喷架构，少走弯路，不踩大坑。会持续输出原创精彩分享，敬请期待！

坚持是一种信仰，在看是一种态度！