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