java 中 BigDecimal 怎么与 0 比较

Posted 2023-04-04

参考技术A 如果不确定 bigDecimal 的范围，可以把 0 转化为 bigDecimal类型的，然后用其 equals方法进行比较
BigDecimal bd1 =... ;//其中的一个bigDecimal对象
BigDecimal bd2 = new BigDecimal(0) //把 0 转为 BigDecimal
就可以用 bd1.CompareTo(bd2) 根据返回值进行比较 参考技术B 调用BigDecimal中的compareTo方法， 如：
int i = bigDecimal.compareTo(new BigDecimal(0));

i=0:表示bigDecimal的值=0
i>0:表示bigDecimal的值与>0
i<0:表示bigDecimal的值与<0 参考技术C 标准做法
int r=big_decimal.compareTo(BigDecimal.Zero); //和0，Zero比较
if(r==0) //等于
if(r==1) //大于
if(r==-1) //小于

或者
if(big_decimal.equals(BigDecimal.Zero)) //是否等于0本回答被提问者和网友采纳 参考技术D if(big_decimal.equals(BigDecimal.Zero)) //是否等于0

这种方式如果big_decimal= new bigDecimal（“0.000”）；
equals结果就是false， 所以还是使用compareTo 判断比较准确 第5个回答  2011-07-22 把0转成BigDecimal不就可以比了吗

Java 中的货币精度（不是 BigDecimal）

【中文标题】Java 中的货币精度（不是 BigDecimal）

【英文标题】：Monetary precision in Java (not BigDecimal)

【发布时间】：2015-02-03 16:57:06

【问题描述】：

我们知道使用 float 或 double 不是需要正确精度的选项，并且我们知道 BigDecimal 可以达到此目的，但我们也知道它比常规原始操作慢大约 100 倍。

如果速度对我们来说至关重要，而我们确实需要精确度，我们该怎么办？

我尝试以最慢的单位存储货币的价值并将其转换存储为 1 BTC = 100000000 satoshi，但经过几次实验，很明显你根本无法长期存储 100BTC，超过了可能的最大值。是的，可以选择牺牲精度，例如存储 microBTC 等，但问题更加全球化，我们如何使用原语设计这样的东西？

【问题讨论】：

我还没有发现 BigDecimal 与原语相比成为瓶颈。您确定它对您的需求来说太慢了吗？

如果您需要任意精度，请使用BigDecimal（或String）。没有 Java 原始类型可以满足您的要求，并且您无法在不使用 Object 的情况下创建新类型。

一百倍的非常小的值不会成为瓶颈。原始操作的规模为一纳秒。微基准与识别瓶颈无关。

Java 的 long 类型的最大值 (2^63)-1。最终将只有 2100 万比特币在流通。 1 BTC = 10^8 satoshis，这意味着总共 2.1*10^15 satoshis。使用 2.1*10^15

学习 D.E.Knuth 的第 2 卷。您可以使用“半数值算法”非常有效地实现定点算法。我已经经历了这些，并且我已经制作了一个类似于 BigInteger 的工作，而无需为每个新的操作结果重新创建一个对象。是的，这意味着工作，但如果你真的认为你需要它......不确定你计划什么算法，但 BigDecimal 并没有那么慢。

【参考方案1】：

正如 D.E.Knuth 在他的第 2 卷“计算机编程的艺术”中充分记录的那样，以任意精度实现算术并不是“魔法” - 请参阅“半数值算法”一章。根据实现 COBOL 计算的必要性（因此：不仅是整数），我已经经历了这一点。

此外，在不为每个新的操作结果重新创建对象的情况下，制作类似于 BigInteger 或 BigDecimal 的工作是一种选择。是的，这意味着工作，但如果你真的认为你需要它......

我发现 BigInteger 就算术而言并没有那么慢。对我来说真正扼杀的是必须经常在二进制和十进制（十进制数字数组）之间进行转换。

【讨论】：

Seminumerical Algorithms 是整卷的标题，而不是一章。您所指的章节标题为算术。

【参考方案2】：

您的选择是：

BigDecimal - 准确且有效 - 比原语慢，但可能无法衡量 - 大部分是不可变的（即可以改变准确性但不能改变价值）。

long - 准确但有价值限制 - 原始，因此在速度方面无法超越 - 不可变 - 数学更容易编写，更清晰。

BigInteger - 可能是您在上述两者之间最好的折衷方案 - 不可变，因此每当您更改值时都必须创建新的 - 您不太可能达到它的极限。

【讨论】：

long 和BigInteger 一样可变，真的。

我不必担心可变性，因为这些值不会在多线程模式下运行......

@Vach - 你会惊讶于 JVM 在重用你放手的对象方面的效率。别担心了。如果存在可衡量的速度问题，请稍后处理。看看here。

@vach 关于 HotSpot 的内存管理，您还需要了解更多信息——例如 Escape Analysis 和根本不在堆上分配的前景，以及常规 Minor GC 和 Major GC 之间的巨大差异。

那是我们的 Peter Lawrey，这里的***人物之一。关于 GC，你错了它必须不运行——Major GC 必须不运行；没有人会担心未成年人。 Major GC 的频率与您创建的垃圾的数量 几乎没有关系——它与对象的生命周期 有关。唯一要避免的是一次保留大量对象，而您的用例根本没有表明这种风险。