Java BigDecimal转换、除法“陷阱”
在Java中经常可以用到double转BigDecimal，也经常进行除法运算，但是以下用法需要特别小心了。
Java代码
package com.ccxe.number;
import java.math.BigDecimal;
import java.math.RoundingMode;
public class Test {
public static void main(String[] args) {
// 打印0.899999999999999911182158029987476766109466552734375
System.out.println(new BigDecimal(2.00).subtract(new BigDecimal(Double
.toString(1.10))));
// double转BigDecimal建议做法
System.out.println(new BigDecimal(Double.toString(2.00))
.subtract(new BigDecimal(1.10)));
// 打印0.90
System.out.println(new BigDecimal("2.00").subtract(new BigDecimal(
"1.10")));
// 异常java.lang.ArithmeticException: Non-terminating decimal expansion;
// System.out.println(new BigDecimal("2.00")
// .divide(new BigDecimal("1.10")));
// 打印1.81818
System.out.println(new BigDecimal("2.00").divide(
new BigDecimal("1.10"), 5, RoundingMode.HALF_EVEN));
}
}package com.ccxe.number;
import java.math.BigDecimal;
import java.math.RoundingMode;public class Test {
public static void main(String[] args) {
// 打印0.899999999999999911182158029987476766109466552734375
System.out.println(new BigDecimal(2.00).subtract(new BigDecimal(Double
.toString(1.10))));
// double转BigDecimal建议做法
System.out.println(new BigDecimal(Double.toString(2.00))
.subtract(new BigDecimal(1.10)));// 打印0.90
System.out.println(new BigDecimal("2.00").subtract(new BigDecimal(
"1.10")));// 异常java.lang.ArithmeticException: Non-terminating decimal expansion;
// System.out.println(new BigDecimal("2.00")
// .divide(new BigDecimal("1.10")));
// 打印1.81818
System.out.println(new BigDecimal("2.00").divide(
new BigDecimal("1.10"), 5, RoundingMode.HALF_EVEN));}
}
一下将解释这一现象。
正文：
引言中的代码样例，指明了两个问题：
1，第11行：执行的结果，居然和18行不同；
2，第22行：除不尽，居然抛出异常。
而且更重要的是，这两个问题在编码时隐蔽性很强~。=
先看第1个问题：
一看到减法结果很长，立马想到1.10在二进制表达时，是不能准确表达的。随后在JDK API中找到了答案。说法如下：
C代码
public BigDecimal(double val)
将 double 转换为 BigDecimal，后者是 double 的二进制浮点值准确的十进制表示形式。返回
的BigDecimal 的标度是使 (10scale × val) 为整数的最小值。
注：
（1）此构造方法的结果有一定的不可预知性。有人可能认为在 Java 中写入new BigDecimal(0.1)
所创建的 BigDecimal 正好等于 0.1（非标度值 1，其标度为 1），但是它实际上等于
0.1000000000000000055511151231257827021181583404541015625。这是因为 0.1 无法准确地表
示为double（或者说对于该情况，不能表示为任何有限长度的二进制小数）。这样，传入 到构
造方法的值不会正好等于 0.1（虽然表面上等于该值）。
（2）另一方面，String 构造方法是完全可预知的：写入 new BigDecimal("0.1") 将创建一个
BigDecimal，它正好 等于预期的 0.1。因此，比较而言，通常建议优先使用 String 构造方法。
（3）当 double 必须用作 BigDecimal 的源时，请注意，此构造方法提供了一个准确转换；
它不提供与以下操作相同的结果：先使用 Double.toString(double) 方法，然后使用
BigDecimal(String) 构造方法，将 double 转换为 String。要获取该结果，请使用
static valueOf(double) 方法。
参数：
val - 要转换为 BigDecimal 的 double 值。
抛出：
NumberFormatException - 如果 val 为无穷大或 NaN。public BigDecimal(double val)
将 double 转换为 BigDecimal，后者是 double 的二进制浮点值准确的十进制表示形式。返回
的BigDecimal 的标度是使 (10scale × val) 为整数的最小值。注：
（1）此构造方法的结果有一定的不可预知性。有人可能认为在 Java 中写入new BigDecimal(0.1)
所创建的 BigDecimal 正好等于 0.1（非标度值 1，其标度为 1），但是它实际上等于
0.1000000000000000055511151231257827021181583404541015625。这是因为 0.1 无法准确地表
示为double（或者说对于该情况，不能表示为任何有限长度的二进制小数）。这样，传入 到构
造方法的值不会正好等于 0.1（虽然表面上等于该值）。
（2）另一方面，String 构造方法是完全可预知的：写入 new BigDecimal("0.1") 将创建一个
BigDecimal，它正好 等于预期的 0.1。因此，比较而言，通常建议优先使用 String 构造方法。
（3）当 double 必须用作 BigDecimal 的源时，请注意，此构造方法提供了一个准确转换；
它不提供与以下操作相同的结果：先使用 Double.toString(double) 方法，然后使用
BigDecimal(String) 构造方法，将 double 转换为 String。要获取该结果，请使用
static valueOf(double) 方法。参数：
val - 要转换为 BigDecimal 的 double 值。
抛出：
NumberFormatException - 如果 val 为无穷大或 NaN。
由此，可以看出，果然又是经典的“10进制无法精确表达为2进制”问题。
再看第二个问题：
从异常信息“Non-terminating decimal expansion ；”（非终止十进制扩张）可以猜出，可能商不能精确表达。于是再查JDK API，找到如下说法：
C代码
public BigDecimal divide(BigDecimal divisor)
返回一个 BigDecimal，其值为 (this / divisor)，其首选标度为 (this.scale()
- divisor.scale())；如果无法表示准确的商值（因为它有无穷的十进制扩展），
则抛出 ArithmeticException。
参数：
补充：软件开发 , Java ,
