在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”)
// .pide(new BigDecimal(“1.10”)));
// 打印1.81818
System.out.println(new BigDecimal(“2.00”).pide(
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”)
// .pide(new BigDecimal(“1.10”)));
// 打印1.81818
System.out.println(new BigDecimal(“2.00”).pide(
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 pide(BigDecimal pisor)
返回一個 BigDecimal，其值為 (this / pisor)，其首選標度為 (this.scale()
– pisor.scale())；如果無法表示準確的商值（因為它有無窮的十進制擴展），
則拋出 ArithmeticException。
參數：
