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<Map<String, Object>> retList = new ArrayList<Map<String, Object>>();
        Map<String, Object> retMap = new HashMap<String, Object>();
        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);
            }
        }
    }
}

引入依赖（低版本）：

<dependency>
    <groupId>com.alibaba</groupId>
    <artifactId>fastjson</artifactId>
    <version>1.2.16</version>
</dependency>

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

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

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

<dependency>
    <groupId>com.alibaba</groupId>
    <artifactId>fastjson</artifactId>
    <version>1.2.70</version>
</dependency>

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

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 对比着看，会发现 低版本的 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<Map<String,Object> 时，不妨先提前 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 升级的事情，也想传达写出规范性的代码，是很有必要，不然升级的时候就很麻烦。代码修炼系列分享，仍会结合实际项目进行继续分享，请各位持续关注。

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

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

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

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

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

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