发现fastjson 2.0.32 版本的一个bug---数据转换错误

最近参与一个新的项目，测试同事发现一个数据不对，数据库的数据明明是 4.12，但是界面显示的却是 0.06171，这个差距太大了吧。。。一路跟踪代码没有发现任何问题，最后debug发现，

jsonObject.toJavaObject(XX.class)  这行代码之后数据就不对了，不会吧，又是fastjson的bug？之前已经遇到一次，数据量太大，fastjson报空指针的问题（版本升级解决），现在又遇到，，，，

老司机第一反应就是，小数嘛，是不是精度问题，但是4.12和0.06171这个精度差距天壤之别，就不大可能了吧，重点是，这个不一定能复现，最后逼得我一行行的debug 源码才发现问题所在。

问题演示

1：出错的代码

直接看有问题的demo代码：

import com.alibaba.fastjson.JSONObject;
import com.google.common.collect.Lists;
import lombok.AllArgsConstructor;
import lombok.Data;
import lombok.NoArgsConstructor;
import java.math.BigDecimal;
import java.util.List;

public class TestSome {
    @Data
    @AllArgsConstructor
    @NoArgsConstructor
    public static class TestB {
        BigDecimal b;
        String name;
    }

    @Data
    @AllArgsConstructor
    @NoArgsConstructor
    public static class TestA {
        int a;
        List<TestB> list;
    }

    public static void main(String[] args) {
        BigDecimal bigDecimal = new BigDecimal("4.12000000000000000000");
        TestA a = new TestA(250, Lists.newArrayList(new TestB(bigDecimal, "你好啊")));
        String s = JSONObject.toJSONString(a);
        JSONObject jsonObject = JSONObject.parseObject(s);
        TestA testA = jsonObject.toJavaObject(TestA.class);
        System.out.println(testA);
    }
}

上面这段代码不要改变里面的 import 和 fastjson版本

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

上面这段代码有什么bug吗？我当时是真没看出来！然而他的运行结果却是

b 的值是0.06171630378389864448。

然后，恶心的来了！

2：无法复现情况

我们把  String number = "4.12000000000000000000";   number的0去掉几个

现在的输出结果是：

会有人想到：是不是数字太大导致的？但是这个是小数，0多几个，也还是4.12，还是

BigDecimal 表示，不存在溢出

2：无法复现情况2

如果是0太多导致的问题，那我加几个0会是什么情况？

这下0够多了吧，惊不惊喜意不意外？结果是正常的，好气哟！办公室又不好发作！

数字长了不行，短了不行，将将好要在这个长度才出问题，过分了啊大哥

3：无法复现情况3

巧了，我还有一个项目，就是之前排查出数据过大，fastjson报空指针的问题那个项目，看了下这里的版本是 2.0.26， 比我现在测试的  2.0.32 版本低一些，那这不是妥妥的要复现吗？

结果我就不贴图了，确实没有复现，低版本反而没问题，你敢信？！

题外：还有其他不能复现的情况，就不详细说了，比如，没有无参构造器，或者参数不是list也没问题。

问题根源：

JSONReaderUTF16  的  readBigDecimal() 方法中  （测试了很多次，发现json中有中文才会走这个类。）

请看源码图：

在代码1处判断是数字，转为10进制 long，每次乘以10， 最后在下面图中转换成 BigDecimal

当时看到这个代码大概就知道了，问题出在 “位溢出“， 下面是第一次出错的值

在循环中每次 乘以 10 ，临界值为 4120000000000000000L  这个数字再乘以10 就超出了long的最大值，是多少呢？

4120000000000000000L  转换成2进制为：

100011101111000011110011011011011010001010000110000000000000000000

这超过了64位，进行截取，然后我们把截取的2进制拿去转成10进制

结果就是 4306511852580896768， 是个正数，为什么我强调是个整数呢？稍后解释，

我们一般看到很多文章都会说位溢出后变成负数，如果到达long的最大值，每次加小一点数字，确实是负数，因为产生的进位，还没有影响到最高位（1为负，0为正），但是这里是 * 10，相当于加了9个 4120000000000000000，这个数截取后会直接影响最高位！！

看到这里就来解释 为什么 "4.120000000000000000"  后多加几个0 反而是对的呢？多加了更应该位溢出啊？

这里是因为fastjson里有个 overflow的标记，当他判断出溢出之后直接用字符串转为 BigDecimal

//这是数字转BigDecimal
decimal = BigDecimal.valueOf(negative ? -longValue : longValue, scale);

//这是字符串转BigDecimal
decimal = TypeUtils.parseBigDecimal(chars, start - 1, len);

但是！！这个overflow的判断条件就有问题了

判断条件是 *10 后的值小于原值，估计作者也是想着：到了最大值，我再加值，应该是负数啊，我判断小于原值不就是位溢出了么，然后就有了下面的代码

也就是说，"4.120000000000000000" 后面添加更多的0，会导致 longValue 被更多次的 *10，总有一次会是负数，然后就标记 overflow = true。 然后用字符串转BigDecimal， 反而正确了！

这就是整个错误原因。

如何修正？

我是直接改成了 fastjson2， 用了最新版，然后删除fastjson 的依赖防止引用错包，这时就没有用 JSONReaderUTF16 解析字符串，问题就解决。

但是 fastjson2 没有 GenericFastJsonRedisSerializer。如果使用了这个类做序列化，需要再引入另一个包

<dependency>
    <groupId>com.alibaba.fastjson2</groupId>
    <artifactId>fastjson2-extension-spring5</artifactId>
</dependency>

具体参考  https://github.com/alibaba/fastjson2/issues/1055