Java中用long/FastMoney替代BigDecimal处理货币的精度与性能疑问

嘿，我来帮你拆解这两个在实时多币种系统里非常实际的问题——之前做支付系统的时候也踩过类似的坑，分享下我的经验：

1. long存货币+double存汇率的运算安全性 #

首先，用long存储以分为单位的货币值是完全安全的，因为分是整数，而long能精确表示所有64位以内的整数，不会有浮点精度丢失的问题。

但用double存储汇率并执行Math.round(money * rate)就不一定安全了，核心原因是double的二进制浮点数特性：

• 很多十进制小数（比如0.1、0.3）无法被二进制浮点数精确表示，会存储为一个近似值
• 当你的money值很大时（比如超过10^12分，也就是10亿级别金额），money * rate的结果可能会因为累积的近似误差，导致Math.round得到错误的整数结果

举个实际的例子：

long money = 1000000000000L; // 1万亿分 = 10亿元
double rate = 0.1;
double result = money * rate;
System.out.println(result); // 输出可能是99999999999.99999而非100000000000.0
System.out.println(Math.round(result)); // 极端场景下可能得到99999999999而非预期值

更安全的替代方案： #

• 用BigDecimal存储汇率：确保汇率的精确性，运算时用BigDecimal.multiply再取整，完全避免误差
• 把汇率也转成整数精度单位：比如汇率精确到万分之一，就用long存储（比如10000代表1.0，3333代表0.3333），这样money * rate就是整数相乘，再除以对应的精度基数（比如10000），用整数运算保证精确性

2. FastMoney计算投资回报率的准确方式 #

FastMoney的设计初衷就是高性能的整数型货币运算，所以它刻意不支持除法——因为除法会产生非整数的货币单位，违背了它用整数存储的核心逻辑。

如果要计算profit.divide(investment)这样的投资回报率，推荐以下两种方式：

方式一：转成BigDecimal做精确计算（推荐） #

把FastMoney实例转成BigDecimal，然后执行除法并设置合适的精度和舍入模式，这样能最大程度保证结果准确：

FastMoney profit = FastMoney.of(12345, "USD"); // 123.45美元利润
FastMoney investment = FastMoney.of(456789, "USD"); // 4567.89美元投资

// 转成BigDecimal（单位为元）
BigDecimal profitBD = BigDecimal.valueOf(profit.getNumber().numberStripped()).divide(BigDecimal.valueOf(100));
BigDecimal investmentBD = BigDecimal.valueOf(investment.getNumber().numberStripped()).divide(BigDecimal.valueOf(100));

// 计算回报率，保留4位小数，用HALF_UP舍入
BigDecimal roi = profitBD.divide(investmentBD, 4, RoundingMode.HALF_UP);

方式二：转成double计算（仅适合小金额场景） #

如果你的金额不会超过2^53（大约9000万亿分，也就是90万亿人民币），转成double计算的误差可以忽略；但如果金额超过这个阈值，double无法精确表示整数，就会出现精度丢失。

示例代码：

double profitDouble = profit.getNumber().numberStripped() / 100.0;
double investmentDouble = investment.getNumber().numberStripped() / 100.0;
double roi = profitDouble / investmentDouble;

这种方式性能最高，但要注意金额上限，避免误差。

总结下：如果追求绝对精确，用BigDecimal；如果追求性能且金额不大，用double。

内容的提问来源于stack exchange，提问作者Mattx