不掌握 BigDecimal 的四大坑你敢用吗?

开发
本文从精度的比较、除法运算中是否设置精度、对象初始化到转字符串,四个角度来把 BigDecimal 的坑尽可能清晰的描述出来,以及基于这些坑得到的优秀实践。

BigDecimal 是 Java 中的一个类,这个相信大家都是知道的。它的作用就是可以表示任意精度的十进制数,BigDecimal 提供了精确的数字运算,适用于需要高精度计算的场景,例如金融、货币或者税收等涉及到金钱的地方。

与 double 和 float 不同的是,BigDecimal 对象在计算的过程中不会丢失精度,那么下面我们就来看下第一个坑,浮点精度的坑。

一、浮点精度的坑

我们先来看一个例子:

    public static void main(String[] args) {

        BigDecimal num1 = new BigDecimal("0.1");
        BigDecimal num2 = new BigDecimal("0.10");

        // false
        System.out.println(num1.equals(num2));
        // 0
        System.out.println(num1.compareTo(num2));

    }

compareTo 方法比较中,a.compareTo(b)

返回:

  • -1: a小于b
  • 0: a等于b
  • 1: a大于b。

在上方的代码中,我们使用 new BigDecimal 的形式 new 了两个 BigDecimal 对象,分别是 0.1 和0.10。

我们分别使用了 equals 与 compareTo 进行比较,当使用 equals 进行比较时,返回了 false,这是因为 equals 不仅比较了值是否相等,还比较了精度是否相等,源码中是这样写的:

 public boolean equals(Object x) {
        if (!(x instanceof BigDecimal))
            return false;
        BigDecimal xDec = (BigDecimal) x;
        if (x == this)
            return true;
        if (scale != xDec.scale)
            return false;
        long s = this.intCompact;
        long xs = xDec.intCompact;
        if (s != INFLATED) {
            if (xs == INFLATED)
                xs = compactValFor(xDec.intVal);
            return xs == s;
        } else if (xs != INFLATED)
            return xs == compactValFor(this.intVal);

        return this.inflated().equals(xDec.inflated());
    }

所以在使用 equals 进行比较两个 BigDecimal 的大小时,一定要注意这一点了。

简单概括一下,如果比较两个 BigDecimal 对象的大小,那就使用 compareTo 方法;如果严格比较精度的大小,那就使用 equals 方法进行比较。

上面我们知道了如何比较两个 BigDecimal 对象的大小,equals 比较的还有他们的精度,那么精度又是如何设置的呢,这块有没有坑呢?

二、设置精度的坑

有的同学可能会说了,设置精度还有啥坑啊,设置了精度就好了吗,哎对,就是这个意思,在做 BigDecimal 对象计算的时候,一定要设置精度。相反,有的同学就不喜欢设置精度,那么这 BUG 不就来了吗。

来看一个例子:

    public static void main(String[] args) {

        BigDecimal num1 = new BigDecimal("1");
        BigDecimal num2 = new BigDecimal("3");

        BigDecimal result = num1.divide(num2); // 默认舍入模式为 UNNECESSARY,会抛出 ArithmeticException


    }

上述的代码在执行结束之后会报错 ArithmeticException ,这是因为默认舍入模式为 UNNECESSARY,所以会抛出 ArithmeticException。

Exception in thread "main" java.lang.ArithmeticException: Non-terminating decimal expansion; no exact representable decimal result.

要解决这个异常也很容易,只需要加上精度即可。

    public static void main(String[] args) {

        BigDecimal num1 = new BigDecimal("1");
        BigDecimal num2 = new BigDecimal("3");

        BigDecimal result = num1.divide(num2, 2,RoundingMode.HALF_UP);
        // 输出:0.33
        System.out.println(result);


    }

那么出现这个异常的原因是什么你考虑过吗?为什么加了精度就不报错了呢?

这个异常在源码中也有说明:

大概意思就是如果在做 divide 运算时,如果商是一个无限小数,而操作的结果是一个精确的数字,那么就会抛出该异常。

不知道大家注意到一点没有,就是上面做除法运算的时候,也就是 BigDecimal result = num1.divide(num2, 2,RoundingMode.HALF_UP); 这行代码的位置,使用了一个新的变量 result 来接收结果值,因为 BigDecimal 是不可变的,因此每次进行运算都会创建一个新的 BigDecimal 对象,所以这一点也是需要注意的,创建的多了可能会产生大量的垃圾对象。

讲完了精度与运算,那么你初始化的方式对吗?

三、初始化的坑

先来看代码:

BigDecimal num = new BigDecimal(0.1); // 使用双精度浮点数构造
System.out.println(num); // 输出: 0.1000000000000000055511151231257827021181583404541015625

BigDecimal num2 = new BigDecimal("0.1"); // 使用字符串构造
System.out.println(num2); // 输出: 0.1

在使用 new BigDecimal 构造器进行初始化的时候,如果有初始值,最好使用字符串的构造方法进行初始化。

在使用 double 的构造器进行新建时,本身传入的 0.1 就是浮点类型了,为了不丢失精度,在使用 new BigDecimal 新建时就把这个近似值完整的保留下来了。

或者就是 另外一种初始化方式 BigDecimal.valueOf(0.1);,通过看源码可以发现,在 valueOf 的内部,将 Double 类型直接转为了字符串了,因此也就不会存在精度丢失的问题了。

对于使用 new BigDecimal(0.1) 构造时,源码中也已经说明了这个问题。

大体意思就是生成的 BigDecimal 对象不是我们想要的 0.1,推荐使用 String 类型的构造方法。

上面我们已经学会了如何初始化,如何运算,下一步就是如何用了,例如转字符串,很多同学可能会说,转字符串 toString() 不就好了,如果你也这样想,那你单纯了弟弟。

四、转字符串的坑

还是先看一段代码:

    public static void main(String[] args) {
        BigDecimal a = BigDecimal.valueOf(89382389312389594.33822312317952678768725);
        System.out.println(a.toString()); // 输出:8.93823893123896E+16
        String str = a.setScale(2, RoundingMode.HALF_UP).toString();
        System.out.println(str); // 输出: 89382389312389600.00

    }

上面代码中是一个非常大的数,我想把他转为字符串,可是在使用 toString() 方法时,打印出来的却是科学计数法。

所以如果想使用 toString() 方法进行转字符串时,可以使用设置精度的方法,但是结果还是与我们的预期有所差别,我们想要的是一模一样的打印出来呢?

那么 toPlainString 就上场了,这个方法返回一个字符串的表示形式,包含所有的有效数字。

代码修改如下:

    public static void main(String[] args) {
        BigDecimal a = BigDecimal.valueOf(89382389312389594.99933822312317952678768725);
        System.out.println(a.toPlainString());
    }

修改之后就可以了吗,不可以,忘了上面说的吗,使用 String 的构造函数吧兄弟,double 类型的构造函数会丢失精度的。

最终代码如下:

    public static void main(String[] args) {
        BigDecimal a = new BigDecimal("89382389312389594.99933822312317952678768725");
        System.out.println(a.toPlainString());
    }

除了上述两种转字符串的方法外,还有一种,就是 toEngineeringString,这个方法也是返回一个字符串,包含有效数字,但是它会使用工程计数法,科学计数法的一种变体,它使用数字的倍数来表示值,使得指数是 3 的倍数。例如,1000会显示为"1E3",而不是"1E+3"。

所以总结就是:

  • toString:返回有效数字,必要的时候使用科学计数法。
  • toPlainString: 不实用任何科学计数法。
  • toEngineeringString:必要的时候使用工程计数法。

五、总结

本文从精度的比较、除法运算中是否设置精度、对象初始化到转字符串,四个角度来把 BigDecimal 的坑尽可能清晰的描述出来,以及基于这些坑得到的优秀实践。

有些场景下推荐使用 BigDecimal ,但是能不用还是不用,比 double 、float 多出来的性能损失得是你能接受的。如果非得用,那上面这几个坑一定要规避。

责任编辑:赵宁宁 来源: 醉鱼Java
相关推荐

2022-07-19 07:30:06

BigDecimal运算float

2023-06-30 08:10:14

JavaBigDecimal

2022-06-06 00:25:09

Golangpanic死锁

2019-10-25 21:39:39

服务器开发工具

2024-08-02 14:52:00

2018-07-06 05:05:07

2011-10-19 10:07:18

桌面虚拟化云计算

2018-01-31 22:30:05

数据科学家数据专家工程师

2022-02-25 08:13:03

物联网IOT

2022-05-11 09:27:15

Linux发行版

2011-03-21 09:01:49

CSS框架

2023-02-17 08:20:24

SQL脚本数据库

2015-07-17 09:50:16

Carthage优劣比较

2011-02-15 09:58:27

Linux服务器系统维护

2014-11-21 09:28:13

2010-09-17 13:27:17

虚拟化

2009-01-13 08:54:51

华为移动CDMA

2013-01-06 10:44:43

微软Windows 8云计算

2016-03-30 11:51:55

2014-03-27 15:57:45

Android组件Activity
点赞
收藏

51CTO技术栈公众号