BigDecimal 比較大小

在模擬hibernate完成sql語句的組裝的時候，在java類型與數據庫類型之間，規定只允許三種類型，日期型對應java.util.Date,數字型對應java.math.BigDecimal,字符型對應java.lang.String。在處理BigDecimal的時候，發現了一些有趣的現象。

• 大小比較：通常我們比較兩個對象是否相等的時候，首先考慮的就是equals方法了。但是，在BigDecimal里面，這個就行不通了。比如：

  java 代碼

  BigDecimal b1=new BigDecimal("1.0");
  BigDecimal b2=new BigDecimal("1.00");
  boolean t=b1.equals(b2);

  
  怎么樣，你認為t是true還是false？它還真是false。BigDecimal的大小比較，1.0與1.00是不相等的，得采用它自帶的compareTo方法：
    

  java 代碼

  int i=b1.compareTo(b2)

  
  這一次，返回的i可能為-1、0、1，分別表示小於、等於、大於

• 構造函數：解決了上面這個問題好像萬事大吉了，結果，我在做測試的時候，又發現了一個莫名其妙的問題，代碼如下：

java 代碼

BigDecimal bd=supplierRecentProductDao.findHistoryReturnRate("001", "001");
assertEquals(bd.compareTo(new BigDecimal(0.15)),0);

計算得到的bd值就是0.15，但是測試它偏偏告訴我：

java 代碼

junit.framework.AssertionFailedError: expected:<1> but was:<0>

加上打印語句一看：

java 代碼

System.out.println("HistoryReturnRate:"+bd+","+new BigDecimal(0.15));

發現結果是這樣的：

java 代碼

HistoryReturnRate:0.150000,0.1499999999999999944488848768742172978818416595458984375

我們的 new BigDecimal(0.15)得到了一個超接近的數“0.1499999999999999944488848768742172978818416595458984375”，但它就是小於0.15。上網查得，BigDecimal有三種構造方式：

java 代碼

BigDecimal(Stirng s),
BigDecimal(int i,int k),
BigDecimal(double d)

,由於浮點運算的原因,要慎用第三種方式,否則就會得到上面的結果。所以，改用

java 代碼

assertEquals(bd.compareTo(new BigDecimal("0.15")),0);

之后,測試順利通過了。

2012-11-07 14:51:00