我希望在一款每秒处理数千个订单和执行报告的低延迟交易应用程序中，使用BigDecimal来表示价格和金额等任意精度数字。
我不会对它们进行太多的数学运算，所以问题不在于BigDecimal本身的性能，而在于大量的BigDecimal对象如何影响应用程序的性能。
我的担忧是，大量短暂存在的BigDecimal对象会给GC带来压力，并导致CMS收集器中更长的Stop-The-World暂停时间——这绝对是我想避免的。
请确认我的顾虑并建议使用BigD以外的替代方案。如果您认为我的顾虑是错误的，请解释一下原因。
更新：
感谢所有回答者。我现在相信使用BigDecimal会影响我的应用程序的延迟（尽管我仍然计划对其进行测量）。
目前我们决定坚持“非常非OOP”的解决方案（但没有精度损失）——使用两个int，一个用于尾数，另一个用于指数。之所以采用这种方法，是因为基本类型被放置在栈上，而不是堆上，因此不受垃圾回收的影响。
BigDecimal 对您来说并不适用，这就是简单如此。在微秒级别的应用中，对象创建和任何十进制数学计算都太昂贵了。BigDecimal 是一项毫无疑问的选择，因为它对应用程序性能影响很小。double（甚至是 float）并承受精度损失，或者使用 long 并以分、十分之一分或 satoshis（最小的记账单位）来衡量所有金额。现在的JVM在处理短暂对象的创建和销毁方面已经相当出色了，所以这不再是过去那样令人担忧的问题。
我建议您先建立一个所需操作的模型并进行测试。这比您可能得到的任何“理论”答案都要有价值 :-)
针对您特定的问题领域，我曾经处理过的类似系统使用double来代替您想要使用BigDecimal的数据，并且重新审视这个领域的思考方式可能是值得的。简单地查看BigDecimal，发现它有5或6个字段，而超过单个double的额外内存消耗可能会抵消您所拥有的任何功能性好处。
BigInteger（而 BigInteger 的一个字段是 int[]）（Sun 实现）。 - Tom Hawtin - tacklineBigDecimal 的性能比起 long、double 或者是 Long 都要慢很多。但这是否会对你的应用程序的性能造成重大影响，还取决于你的应用程序。
我建议找出你的应用程序中最慢的部分，并对其进行比较测试。它是否仍然足够快？如果不是，你可能需要编写一个小的不可变类，其中包含一个单独的 long，并可能检查溢出情况。
如果您实际上正在进行数字必须相加且精度绝对重要的交易，则double不是一个选择。也许您可以将应用程序的这两个部分分开，并仅在交易部分中使用BigDecimal。
如果这不可能，那么你就非常倒霉了。您需要一个BCD数学库，而我认为Java没有这样的库。您可以尝试编写自己的库，但这将是很多工作，并且结果可能仍然无法竞争。
我在一个团队工作，负责对应用程序进行性能评估和优化。我们最近遇到了一个使用 Java Big Decimal 的应用程序，发现存在内存利用方面的显著性能问题。后来我们转而使用牛顿-拉弗森算法，在保持计算精度的同时，大幅提升了性能表现，相比之下要好得多。
另外补充一点，在使用 double 类型时，如预期所料，我们发现精度严重下降。
我不确定您的要求是什么，但通常在进行财务计算时，人们不能容忍由浮点类型引起的精度损失。通常情况下，处理货币时准确性和适当的舍入比效率更重要。
如果您不必处理百分比，并且所有金额都是整数，则可以使用整数类型（int、long甚至BigInteger），其中一个表示您的货币单位的0.01。
即使您认为可以承受使用double类型的精度损失，也值得先尝试BigDecimal并检查它是否真的对您来说太慢。