作者最近开发项目, 需要用到java的金钱处理类BigDecimal.
对此很多有和我一样,肯定有疑惑,一般的金钱用Double就行,怎么整出个BigDecimal类?why?
其实,这和计算机的设计有关,原因在于我们的计算机是二进制的。浮点数没有办法是用二进制进行精确表示。
计算机CPU表示浮点数由两个部分组成:指数和尾数,这样的表示方法一般都会失去一定的精确度,有些浮点数运算也会产生一定的误差。
Float和Double类型的主要设计目标是为了科学计算和工程计算。他们执行二进制浮点运算,这是为了在广域数值范围上提供较为精确的快速近似计算而精心设计的。
然而,它们没有提供完全精确的结果,所以不应该被用于要求精确结果的场合。
因此,Float和Double只能用來做科学计算或者是工程计算,在商业计算中我们要用java.math.BigDecimal
BigDecimal提供了丰富的构造函数,可以通过int、long、double、String等来构造一个BigDecimal对象。
构造器描述
BigDecimal(int) 创建一个具有参数所指定整数值的对象。
BigDecimal(double) 创建一个具有参数所指定双精度值的对象。
BigDecimal(long) 创建一个具有参数所指定长整数值的对象。
BigDecimal(String) 创建一个具有参数所指定以字符串表示的数值的对象
那么这几种不同的类型构造出的BigDecimal对象有区别么?
当然是有的.
我们做如下测试:
BigDecimal a = new BigDecimal(1.1);
BigDecimal b = BigDecimal.valueOf(1.1);
BigDecimal c = new BigDecimal("1.1");
System.out.println("a="+a);
System.out.println("b="+b);
System.out.println("c="+c);
结果
a=1.100000000000000088817841970012523233890533447265625
b=1.1
c=1.1
可以看出,Double类型的初始化显然是有问题的,为什么?
因为计算机01的方式对于十进制的0.1是无法精确表示的,所以对于Double数字只能接近表示,如果用这个Double来初始化BigDecimal的话就会出现问题。
我看看看对此现象的官方描述:
2 .另一方面,String 构造方法是完全可预知的:写入 newBigDecimal(“0.1”) 将创建一个 BigDecimal,它正好等于预期的 0.1。因此,比较而言,通常建议优先使用String构造方法。
但是,有时候我们不得不用Double来初始化BidDecimal,此时,我们请使用Double.toString(double)转成String,然后使用String构造方法,或使用BigDecimal的静态方法valueOf.
所以总结一下,推荐使用string类型来初始化BigDecimal
通常有如下三种方法
//方法一
BigDecimal bg1 = new BigDecimal("1.1");
//方法二
BigDecimal bg2 = new BigDecimal(Double.toString(1.1));
//方法三
BigDecimal bg3 = BigDecimal.valueOf(1.1);
BigDecimal.value(double val)方法为什么可以呢?
看看源码的实现:
public static BigDecimal valueOf(double val) {
return new BigDecimal(Double.toString(val));
}
//加法
BigDecimal result1 = num1.add(num2);
BigDecimal result12 = num12.add(num22);
//减法
BigDecimal result2 = num1.subtract(num2);
BigDecimal result22 = num12.subtract(num22);
//乘法
BigDecimal result3 = num1.multiply(num2);
BigDecimal result32 = num12.multiply(num22);
//除法
BigDecimal result5 = num2.divide(num1,20,BigDecimal.ROUND_HALF_UP);
BigDecimal result52 = num22.divide(num12,20,BigDecimal.ROUND_HALF_UP);
//绝对值
BigDecimal result4 = num3.abs();
BigDecimal result42 = num32.abs();
这里有一点需要注意的是除法运算divide.
BigDecimal除法可能出现不能整除的情况,比如 4.5/1.3,这时会报错
java.lang.ArithmeticException: Non-terminating decimal expansion; no exact representable decimal result.
divide方法有两个重载的方法,
两个参数的方法:
divide(传入除数, 传入round的模式)
三个参数的方法:
divide(传入除数, 传入精度, 传入round的模式)
所以,为了避免除不尽的情况,我们需要传入精度参数
num1.divide(num2, 2, BigDecimal.ROUND_HALF_UP);
所以,如果用BigDecimal做除法的时候,一定要在divide方法中传递第二个参数,定义精确到小数点后几位,否则在不整除的情况下,结果是无限循环小数时,就会抛出以上异常。
ROUND_UP
舍入远离零的舍入模式。
在丢弃非零部分之前始终增加数字(始终对非零舍弃部分前面的数字加1)。
注意,此舍入模式始终不会减少计算值的大小。
ROUND_DOWN
接近零的舍入模式。
在丢弃某部分之前始终不增加数字(从不对舍弃部分前面的数字加1,即截短)。
注意,此舍入模式始终不会增加计算值的大小。
ROUND_CEILING
接近正无穷大的舍入模式。
如果 BigDecimal 为正,则舍入行为与 ROUND_UP 相同;
如果为负,则舍入行为与 ROUND_DOWN 相同。
注意,此舍入模式始终不会减少计算值。
ROUND_FLOOR
接近负无穷大的舍入模式。
如果 BigDecimal 为正,则舍入行为与 ROUND_DOWN 相同;
如果为负,则舍入行为与 ROUND_UP 相同。
注意,此舍入模式始终不会增加计算值。
ROUND_HALF_UP
向“最接近的”数字舍入,如果与两个相邻数字的距离相等,则为向上舍入的舍入模式。
如果舍弃部分 >= 0.5,则舍入行为与 ROUND_UP 相同;否则舍入行为与 ROUND_DOWN 相同。
注意,这是我们大多数人在小学时就学过的舍入模式(四舍五入)。
ROUND_HALF_DOWN
向“最接近的”数字舍入,如果与两个相邻数字的距离相等,则为上舍入的舍入模式。
如果舍弃部分 > 0.5,则舍入行为与 ROUND_UP 相同;否则舍入行为与 ROUND_DOWN 相同(五舍六入)。
ROUND_HALF_EVEN
向“最接近的”数字舍入,如果与两个相邻数字的距离相等,则向相邻的偶数舍入。
如果舍弃部分左边的数字为奇数,则舍入行为与 ROUND_HALF_UP 相同;
如果为偶数,则舍入行为与 ROUND_HALF_DOWN 相同。
注意,在重复进行一系列计算时,此舍入模式可以将累加错误减到最小。
此舍入模式也称为“银行家舍入法”,主要在美国使用。四舍六入,五分两种情况。
如果前一位为奇数,则入位,否则舍去。
以下例子为保留小数点1位,那么这种舍入方式下的结果。
1.15>1.2 1.25>1.2
ROUND_UNNECESSARY
断言请求的操作具有精确的结果,因此不需要舍入。
如果对获得精确结果的操作指定此舍入模式,则抛出ArithmeticException。