java BigDecimal任意精度整数为何慢

在 Java 里，BigDecimal 之所以“慢”，核心原因在于：它本质上不是原生数据类型，而是用对象 + 任意精度算法模拟十进制运算，每一步都要做额外工作。

下面分层解释为什么慢，以及“任意精度整数”这一块具体贵在哪里。

一、BigDecimal 不是机器原生类型

1. 原生类型的快

int a = 1;
int b = 2;
int c = a + b; // CPU 一条指令

• 直接由 CPU 寄存器/ALU 完成
• 固定宽度（32/64 位）
• 零对象开销

2. BigDecimal 的慢

BigDecimal a = new BigDecimal("1");
BigDecimal b = new BigDecimal("2");
BigDecimal c = a.add(b);

背后发生了：

• 对象创建
• 数组（int[] / long[]）存储“数字”
• 十进制 → 二进制内部表示
• 任意精度加法算法
• 新的 BigDecimal 对象返回

二、任意精度整数本身就很昂贵

1. 数字不是“一个数”，而是一串“块”

BigDecimal 内部（类似 BigInteger）：

int[] mag; // 存的是二进制大整数
int scale; // 小数位

例如：

123456789012345678901234567890

会被拆成多个 int（32 位块）存储。

➡ 越大越慢，不是常数时间

2. 加法都要“手动算”

即使是加法：

• 对齐位数
• 按块加
• 处理进位
• 可能扩容数组

对比 CPU 原生加法：

• 一条指令
• 无循环
• 无分支

3. 乘法是 O(n²) 甚至更糟

BigDecimal 乘法：

• 整数乘法（Karatsuba / 普通）
• 再处理 scale（小数点位置）

大数乘法复杂度：

• 普通：O(n²)
• Karatsuba：O(n^1.58)
• FFT（超大数）：更复杂

➡ 远超 long * long

三、Decimal（十进制）比 Binary 更慢

这是 BigDecimal 比 BigInteger 还慢的关键点。

1. 计算机是二进制的

CPU：

• 二进制加法快
• 十进制没有原生支持

2. BigDecimal 必须“模拟十进制”

比如：

0.1 + 0.2

内部要做：

• 转成整数（×10^scale）
• 整数运算
• 再还原小数

而：

double a = 0.1;
double b = 0.2;

只是浮点寄存器一次加法（虽然不精确）

四、不可变对象带来的额外成本

BigDecimal 是 immutable：

BigDecimal c = a.add(b);

意味着：

• 不能修改 a
• 必须新建对象
• 频繁 GC 压力

在循环中尤其明显：

BigDecimal sum = BigDecimal.ZERO;
for (...) {
    sum = sum.add(x); // 每次新建
}

五、为什么“任意精度”必须慢（本质原因）

精度 ≠ 免费

六、什么时候慢得明显？

慢在：

• 大数（几百位以上）
• 高频运算（循环、批处理）
• 金融之外的科学计算

不慢在：

• 金额计算（几十位）
• 低频业务代码

七、优化 / 替代思路

1. 减少对象创建

BigDecimal[] cache = ...

2. 用 BigInteger（如果不需要小数）

• 少一层 scale 处理

3. 用 long / int（如果范围够）

• 最快

4. 使用第三方库

• fast-decimal
• jdk.incubator.vector（未来方向）

一句话总结

BigDecimal 慢，是因为它用“软件算法 + 对象 + 十进制模拟”来换取“任意精度和正确小数”，而这些在 CPU 层面本来是不存在的。

如果你愿意，我也可以：

• 对比 BigDecimal vs double 性能测试
• 解释 BigInteger 内部是怎么算乘法的
• 讲金融系统为什么“宁愿慢也要用 BigDecimal”