我想使用BigDecimal来表示低延迟交易应用程序中的任意精度数字，如价格和金额，每秒有数千个订单和执行报告。
我不会对它们进行很多数学运算，所以问题不在于 BigDecimal 本身的性能，而在于大量的 BigDecimal 对象将如何影响应用程序的性能。
我担心的是，大量短暂的BigDecimal对象会给GC带来压力，并导致CMS收集器中更大的Stop-The-World暂停 - 这绝对是我想避免的。
您能确认我的担忧并提出使用BigD的替代方案吗？另外，如果您认为我的担忧是错误的 - 请解释为什么。
更新：
感谢所有回答的人。我现在确信使用BigDecimal会损害我的应用程序的延迟（即使我仍然计划测量它）。
目前，我们决定坚持使用“非常非OOP”的解决方案（但没有准确性命中） - 使用两个s，一个用于尾数，另一个用于指数。这背后的基本原理是，基元被放置在堆栈上，而不是堆上，因此不受垃圾回收的影响。int
如果您正在开发一个低延迟交易程序，并且您真的想在延迟方面进行竞争，那么就不适合您，它就这么简单。在微秒很重要的地方，对象创建和任何十进制数学都太昂贵了。BigDecimal
我认为，对于几乎所有其他人来说，使用是一件轻而易举的事情，因为它对应用程序性能几乎没有明显的影响。BigDecimal
在做出交易决策的延迟关键型系统中，任何不可预测的垃圾回收暂停都是完全不可能的，因此，虽然当前的垃圾收集算法在正常使用中非常棒，但当5毫秒的延迟可能会花费您很多钱时，它们不一定合适。我希望大型系统是用一种非常非OOP的风格编写的，除了一些滞留的字符串（用于代码等）之外，很少或根本没有使用对象。
您当然需要使用双倍（甚至浮动）并接受准确性打击，或者使用长以美分，十分之一美分或satoshis（无论最小的记账单位是多少）来衡量所有金额。
如今，在处理短期对象的创建和破坏方面，JVM非常好，所以这不是曾经的担忧。
我建议建立一个你想做什么的模型，并衡量它。这将比您可能得到的任何“理论”答案更有价值：-）
看看你的特定问题领域，我过去研究过的类似系统使用双精度系统很好地使用了双精度值来表示你想要使用BigDecimal的数据，这可能值得重新审视你在这个领域的想法。粗略地看一眼 BigDecimal 就会发现它有 5 或 6 个字段，单个双精度值的额外内存消耗可能会超过您拥有的任何功能优势。
