最近有空写了点老的J2EE的代码，发现有一个十分有意思的问题，当用Hibernate从数据库里把浮点数读取出来的时候做一些比如累加的工作，例如 summary 或者递减之类的，就会发现在最后的结果中会出现些许问题。
如：3.41+5.2+56.2+23.3+... （这类两位小数的价钱），结果会出现103.00000000000001这种结果，但是人算的话反而会得出正常的数据。看样子double，float这类数据精度上来了还会有这类问题。
于是，翻了点资料，在有的编程语言中提供了专门的货币类型来处理这种情况，但是Java没有。
四舍五入
我们的第一个反应是做四舍五入。Math类中的round方法不能设置保留几位小数，我们只能
象这样（保留两位）：
public double round(double value){
return Math.round(value*100)/100.0;
}
非常不幸，上面的代码并不能正常工作，给这个方法传入4.015它将返回4.01而不是4.02，
如我们在上面看到的
4.015*100=401.49999999999994
因此如果我们要做到精确的四舍五入，不能利用简单类型做任何运算
java.text.DecimalFormat也不能解决这个问题：
System.out.println(new java.text.DecimalFormat("0.00").format(4.025));
输出是4.02
BigDecimal
在《Effective Java》这本书中也提到这个原则，float和double只能用来做科学计算或者
是工程计算，在商业计算中我们要用 java.math.BigDecimal。BigDecimal一共有4个够造方
法，我们不关心用BigInteger来够造的那两个，那么还有两个，它们是：
BigDecimal(double val)
Translates a double into a BigDecimal.
BigDecimal(String val)
Translates the String repre sentation of a BigDecimal into a
BigDecimal.
上面的API简要描述相当的明确，而且通常情况下，上面的那一个使用起来要方便一些。我
们可能想都不想就用上了，会有什么问题呢？等到出了问题的时候，才发现上面哪个够造方
法的详细说明中有这么一段：
Note: the results of this constructor can be somewhat unpredictable. One might
assume that new BigDecimal(.1) is exactly equal to .1, but it is actually equal
to .1000000000000000055511151231257827021181583404541015625. This is so because
.1 cannot be represented exactly as a double (or, for that matter, as a binary
fraction of any finite length). Thus, the long value that is being passed in to
the constructor is not exactly equal to .1, appearances nonwithstanding.
The (String) constructor, on the other hand, is perfectly predictable: new
BigDecimal(".1") is exactly equal to .1, as one would expect. Therefore, it is
generally recommended that the (String) constructor be used in preference to
this one.
原来我们如果需要精确计算，非要用String来够造BigDecimal不可！在《Effective Java》
一书中的例子是用String来够造BigDecimal的，但是书上却没有强调这一点，这也许是一个
小小的失误吧。
解决方案
现在我们已经可以解决这个问题了，原则是使用BigDecimal并且一定要用String来够造。
但是想像一下吧，如果我们要做一个加法运算，需要先将两个浮点数转为String，然后够造
成BigDecimal，在其中一个上调用add方法，传入另一个作为参数，然后把运算的结果（
BigDecimal）再转换为浮点数。你能够忍受这么烦琐的过程吗？下面我们提供一个工具类
Arith来简化操作。它提供以下静态方法，包括加减乘除和四舍五入：
public static double add(double v1,double v2)
public static double sub(double v1,double v2)
public static double mul(double v1,double v2)
public static double div(double v1,double v2)
public static double div(double v1,double v2,int scale)
public static double round(double v,int scale)
附录
源文件Arith.java：
package com.common.util;
import java.math.BigDecimal;
public final class Arith {
// 默认除法运算精度
private static final int DEF_DIV_SCALE = 2;
// 这个类不能实例化
private Arith() {
}
public static double add(double v1, double v2) {
BigDecimal b1 = new BigDecimal(Double.toString(v1));
BigDecimal b2 = new BigDecimal(Double.toString(v2));
return b1.add(b2).doubleValue();
}
public static double sub(double v1, double v2) {
BigDecimal b1 = new BigDecimal(Double.toString(v1));
BigDecimal b2 = new BigDecimal(Double.toString(v2));
return b1.subtract(b2).doubleValue();
}
public static double mul(double v1, double v2) {
BigDecimal b1 = new BigDecimal(Double.toString(v1));
BigDecimal b2 = new BigDecimal(Double.toString(v2));
return b1.multiply(b2).doubleValue();
}
public static double div(double v1, double v2) {
return div(v1, v2, DEF_DIV_SCALE);
}
public static double div(double v1, double v2, int scale) {
if (scale < 0) {
throw new IllegalArgumentException(
"The scale must be a positive integer or zero");
}
BigDecimal b1 = new BigDecimal(Double.toString(v1));
BigDecimal b2 = new BigDecimal(Double.toString(v2));
return b1.divide(b2, scale, BigDecimal.ROUND_HALF_UP).doubleValue();
}
public static double round(double v, int scale) {
if (scale < 0) {
throw new IllegalArgumentException(
"The scale must be a positive integer or zero");
}
BigDecimal b = new BigDecimal(Double.toString(v));
BigDecimal one = new BigDecimal("1");
return b.divide(one, scale, BigDecimal.ROUND_HALF_UP).doubleValue();
}
}
呵呵，float和double只能用来做科学计算或者是工程计算，在商业计算中我们要用 java.math.BigDecimal。这个才是解决的方式，我也试过了发现确实不错。不过话又说回来了，在.net里似乎没有发现有这类问题呀，能说他好么？我看未必，有时候封装的太好，功能太多，往往让人忘记了这些背后本来的面目：）