我注意到这个构造函数非常痛苦（即使在Stack Overflow上也是如此）。即使文档明确指出，人们也使用它：
此构造函数的结果可能有些不可预测 http://java.sun.com/javase/6/docs/api/java/math/BigDecimal.html#BigDecimal（双精度）
可能被弃用的现有规范：我们建议弃用 BigDecimal（double） 构造函数，该构造函数目前给出的结果与 Double.toString（） 方法不同。
尽管如此，构造函数尚未被弃用。
我很想听听对此的任何看法。
考虑到BigDecimal（double）的行为是正确的，在我看来，我不太确定它是否真的会是一个问题。
我不完全同意构造函数中文档的措辞：BigDecimal(double)
此构造函数的结果可能有些不可预测。有人可能会假设用Java编写会创建一个完全等于（未缩放的值，缩放比例为），但它实际上等于 。
new BigDecimal(0.1)BigDecimal0.1110.1000000000000000055511151231257827021181583404541015625
（着重号是后加的。
与其说不可预测，我认为措辞应该是出乎意料的，即便如此，对于那些没有意识到用浮点值表示十进制数的局限性的人来说，这将是意想不到的行为。
只要记住浮点值不能精确地表示所有十进制值，使用 be 返回的值实际上就有意义。BigDecimal(0.1)0.1000000000000000055511151231257827021181583404541015625
如果构造函数实例化的对象是一致的，那么我认为结果是可预测的。BigDecimalBigDecimal(double)
我对为什么构造函数没有被弃用的猜测是，因为行为可以被认为是正确的，只要知道浮点表示是如何工作的，构造函数的行为就不太令人惊讶。BigDecimal(double)
弃用已弃用。仅在特殊情况下，API 的某些部分才会被标记为已弃用。
因此，在生成过程中运行 FindBugs。FindBugs有一个探测器PlugIn API，也是开源的（LGPL，IIRC）。
