为什么不用Double存储金额，有何替代方案？

众所周知,double 和 float 这些浮点数其实是不精确的。 比如 0.1 + 0.2 并不等于 0.3,而是等于 0.30000000000000004——这也一度成为程序员圈子里的经典梗。所以用浮点数表示金额这种需要精确计算的数值,是会出现精度丢失问题的。 double a = 0.1; double b = 0.2; System.out.println(a + b); // 输出: 0.30000000000000004 System.out.println(a + b == 0.3); // 输出: false 再看一个更实际的例子,假设你在做一个电商系统的金额计算: double price = 2.0; double discount = 0.9; System.out.println(price * discount); // 输出: 1.7999999999999998 你看,原本应该是 1.8 的结果,却变成了 1.7999999999999998。如果这是真实的订单金额,那可就出大问题了 为什么会精度丢失 为什么会有这种精度丢失呢?因为计算机底层都是用二进制存储的,但并不是所有十进制数都能用二进制精确表示。各位有兴趣的话可以试着算一下 0.1 的二进制是多少,算出来可以在评论区分享一下。 算了一会你可能会发现:这怎么算不完?没错,出现了无限循环的情况——(0.1)₁₀ = (0.000110011001100...)₂ 像这种情况,计算机就没办法用二进制精确表示 0.1 了。 而 double 类型在 Java 中占 64 位,按照 IEEE 754 标准,其中 1 位是符号位,11 位是指数位,52 位是尾数位。当遇到无限循环的二进制小数时,只能截断保存,这就导致了精度丢失。 BigDecimal 在 Java 中,无论是单精度还是双精度,表示的都是近似值。 为了表示精确的小数值，Java 提供了 BigDecimal 类型。BigDecimal 由两个部分组成：无标度值(unscaled value)和标度(scale)。无标度值是一个整数,表示实际的数值;标度也是一个整数,表示小数点后的位数。 举个例子,数字 123.45 在 BigDecimal 中: 无标度值是 12345 标度是 2 实际值就是:12345 × 10⁻² = 123.45 用 BigDecimal 来处理刚才的金额计算: BigDecimal price = new BigDecimal("2.0"); BigDecimal discount = new BigDecimal("0.9"); BigDecimal result = price.multiply(discount); System.out.println(result); // 输出: 1.80 这下结果就对了 equals 的坑 在 BigDecimal 中不能用 equals 方法做等值比较,因为 equals 会同时比较无标度值和标度这两个内容。 BigDecimal a = new BigDecimal("0.1"); BigDecimal b = new BigDecimal("0.10"); System.out.println(a.equals(b)); // 输出: false 我们都知道 0.1 和 0.10 在数值上是相等的,但 equals 的结果却是 false。这是因为: a 的无标度值是 1,标度是 1 b 的无标度值是 10,标度是 2 虽然值相同,但它们的标度不同,所以 equals 返回 false。 compareTo 比较 BigDecimal 大小时应该使用 compareTo 方法,返回值为 1、-1、0,分别代表大于、小于、等于。