我注意到这个构造函数非常痛苦（即使在 Stack Overflow 上也是如此）。即使文档明确指出，人们也会使用它：
这个构造函数的结果可能有些不可预测 http://java.sun.com/javase/6/docs/api/java/math/BigDecimal.html#BigDecimal(double)
我什至看到JSR-13 是APPROVED 并附有推荐说明：
可能被弃用的现有规范：我们建议弃用 BigDecimal(double) 构造函数，它目前给出的结果与 Double.toString() 方法不同。
尽管如此，构造函数尚未被弃用。
我很想听听对此的任何看法。
【问题讨论】：
标签： java api bigdecimal
考虑到BigDecimal(double) 的行为是正确的，在我看来，我不太确定它是否真的会是这样的问题。
我不完全同意 BigDecimal(double) 构造函数中文档的措辞：
这个构造函数的结果可以是 有点不可预测。一个可能 假设用 Java 编写
new BigDecimal(0.1)会创建一个BigDecimal正好等于0.1（未缩放的值1，缩放为1），但实际上是相等的 到0.1000000000000000055511151231257827021181583404541015625.
（已添加重点。）
与其说unpredictable，我认为措辞应该unexpected，即便如此，这对于那些不知道representation的局限性的人来说也是意想不到的行为floating point values 的十进制数。
只要记住浮点值不能精确地表示所有十进制值，使用BigDecimal(0.1)返回的值是0.1000000000000000055511151231257827021181583404541015625实际上是有意义的。
如果BigDecimal(double) 构造函数实例化的BigDecimal 对象是一致的，那么我认为结果是可预测的。
我猜测为什么BigDecimal(double) 构造函数没有被弃用是因为它的行为可以被认为是正确的，只要知道浮点表示是如何工作的，构造函数的行为就不会太令人惊讶了。
【讨论】：
弃用已弃用。部分 API 仅在特殊情况下被标记为弃用。
因此，在构建过程中运行 FindBugs。 FindBugs 有一个检测器插件 API，也是开源的（LGPL、IIRC）。
【讨论】：
与所有浮点运算一样，该特定构造函数是一个近似值。它不是真的坏，它只是有缺点。
只要做你的研究，小心处理它，你不会得到任何惊喜。将十进制文字分配给双精度/浮点数时，您会遇到完全相同的事情。
【讨论】：