The result of floating point number is not exact, which makes them unsuitable for any financial calculation which requires exact result and not approximation. float and double are designed for engineering and scientific calculation and many times doesn’t produce exact result also result of floating point calculation may vary from JVM to JVM. Look at below example of BigDecimal and double primitive which is used to represent money value, its quite clear that floating point calculation may not be exact and one should use BigDecimal for financial calculations.

    // floating point calculation
    final double amount1 = 2.0;
    final double amount2 = 1.1;
    System.out.println("difference between 2.0 and 1.1 using double is: " + (amount1 - amount2));

    // Use BigDecimal for financial calculation
    final BigDecimal amount3 = new BigDecimal("2.0");
    final BigDecimal amount4 = new BigDecimal("1.1");
    System.out.println("difference between 2.0 and 1.1 using BigDecimal is: " + (amount3.subtract(amount4)));

输出:

difference between 2.0 and 1.1 using double is: 0.8999999999999999
difference between 2.0 and 1.1 using BigDecimal is: 0.9

这不是精确与否的问题，也不是精确与否的问题。这是一个满足以10为底而不是以2为底计算的人的期望的问题。例如，在财务计算中使用双精度值不会产生数学意义上的“错误”答案，但它可以产生财务意义上不期望的答案。

即使您在输出前的最后一分钟舍入结果，您仍然可以偶尔使用与期望不匹配的双精度结果。

Using a calculator, or calculating results by hand, 1.40 * 165 = 231 exactly. However, internally using doubles, on my compiler / operating system environment, it is stored as a binary number close to 230.99999... so if you truncate the number, you get 230 instead of 231. You may reason that rounding instead of truncating would have given the desired result of 231. That is true, but rounding always involves truncation. Whatever rounding technique you use, there are still boundary conditions like this one that will round down when you expect it to round up. They are rare enough that they often will not be found through casual testing or observation. You may have to write some code to search for examples that illustrate outcomes that do not behave as expected.

Assume you want to round something to the nearest penny. So you take your final result, multiply by 100, add 0.5, truncate, then divide the result by 100 to get back to pennies. If the internal number you stored was 3.46499999.... instead of 3.465, you are going to get 3.46 instead 3.47 when you round the number to the nearest penny. But your base 10 calculations may have indicated that the answer should be 3.465 exactly, which clearly should round up to 3.47, not down to 3.46. These kinds of things happen occasionally in real life when you use doubles for financial calculations. It is rare, so it often goes unnoticed as an issue, but it happens.

如果您使用以10为基数进行内部计算，而不是使用双数，则如果您的代码中没有其他错误，那么结果总是完全符合人类的预期。

大多数回答都强调了为什么不应该使用替身来计算金钱和货币。我完全同意他们的观点。

但这并不是说，double永远不能用于这个目的。

我曾经参与过许多gc需求非常低的项目，BigDecimal对象是造成这种开销的一个重要因素。

正是由于缺乏对双重表示的理解，以及缺乏处理准确性和精确性的经验，才产生了这个明智的建议。

如果您能够处理项目的精度和准确性要求，则可以使其工作，这必须基于处理的双精度值的范围来完成。

你可以参考番石榴的FuzzyCompare方法来获得更多的信息。参数公差是关键。 我们为一个证券交易应用程序处理了这个问题，并对在不同范围内对不同数值使用什么公差做了详尽的研究。

此外，在某些情况下，您可能会试图使用Double包装器作为映射键，并将哈希映射作为实现。这是非常危险的，因为双重。等号和哈希码，例如值“0.5”和“0.6 - 0.1”将导致一个大混乱。

为了补充前面的答案，在处理问题中解决的问题时，除了BigDecimal之外，还可以选择在Java中实现Joda-Money。Java模块名称为org.joda.money。

它需要Java SE 8或更高版本，并且没有依赖关系。

更准确地说，存在编译时依赖关系，但它不是 必需的。

<dependency>
  <groupId>org.joda</groupId>
  <artifactId>joda-money</artifactId>
  <version>1.0.1</version>
</dependency>

使用Joda Money的例子:

  // create a monetary value
  Money money = Money.parse("USD 23.87");
  
  // add another amount with safe double conversion
  CurrencyUnit usd = CurrencyUnit.of("USD");
  money = money.plus(Money.of(usd, 12.43d));
  
  // subtracts an amount in dollars
  money = money.minusMajor(2);
  
  // multiplies by 3.5 with rounding
  money = money.multipliedBy(3.5d, RoundingMode.DOWN);
  
  // compare two amounts
  boolean bigAmount = money.isGreaterThan(dailyWage);
  
  // convert to GBP using a supplied rate
  BigDecimal conversionRate = ...;  // obtained from code outside Joda-Money
  Money moneyGBP = money.convertedTo(CurrencyUnit.GBP, conversionRate, RoundingMode.HALF_UP);
  
  // use a BigMoney for more complex calculations where scale matters
  BigMoney moneyCalc = money.toBigMoney();

文档: http://joda-money.sourceforge.net/apidocs/org/joda/money/Money.html 实现示例: https://www.programcreek.com/java-api-examples/?api=org.joda.money.Money

如果你的计算涉及到不同的步骤，任意的精度算法都不能100%覆盖你。

使用完美的结果表示(使用自定义Fraction数据类型，将除法操作批处理到最后一步)并且仅在最后一步转换为十进制的唯一可靠方法。

任意精度不会有帮助，因为总有可能有很多小数点后的数字，或者一些结果，如0.6666666……最后一个例子没有任意的表示法。所以每一步都会有小误差。

这些错误会累积起来，最终可能变得不再容易被忽视。这被称为错误传播。

我将冒着被否决的风险，但我认为浮点数在货币计算中的不适用性被高估了。只要确保正确地进行了舍入，并且有足够的有效数字来处理zneak解释的二进制十进制表示不匹配，就不会有问题。

在Excel中使用货币计算的人总是使用双精度浮点数(Excel中没有货币类型)，我还没有看到有人抱怨舍入错误。

当然，你必须在合理范围内;例如，一个简单的网络商店可能永远不会遇到双精度浮点数的任何问题，但如果你做会计或其他需要添加大量(无限制)数字的事情，你不会想要用十英尺的杆子触摸浮点数。