Java常用类核心要点：包装类、BigDecimal精度与随机数实战-平芜编程栈

1. 包装类到底解决什么问题——先聊设计思路

1.1 基本类型不是对象，集合又只收对象

Java有两套类型体系：一套是基本类型（int、double、boolean这些），另一套是引用类型（String、数组、各种类对象）。这两套体系在JVM里的存储方式完全不一样，基本类型直接存值，堆上都留不下痕迹；引用类型存的是地址，对象本体活在堆内存里。

问题就出在集合上。你用List、Map、Set的时候，泛型参数不能写int、double，只能写Integer、Double。为什么？因为集合底层要用Object数组或者链表节点来存元素，基本类型没法塞进Object。这就很尴尬，早期学Java的人肯定遇到过这种报错：List<int> list = new ArrayList<>();编译直接不给过。想存一组数字，只能老老实实写List<Integer>。包装类就是为这种场景准备的，它把基本类型“包”成一个对象，让基本类型也能进集合、也能参与泛型。

再往深了说，包装类的存在还解决了一个NPE问题——不对，准确说是引入了一个NPE问题。后续我会专门讲这个坑，但设计初衷确实是给基本类型穿上对象的外衣，让它能融入面向对象的世界。JDK 1.0时代就设计了8个包装类，分别对应byte、short、int、long、float、double、char、boolean，一直到今天都没变化，可见这玩意儿有多稳定、多基础。

1.2 装箱与拆箱：自动帮你做的类型转换

包装类和基本类型之间可以互相转换，分两种：

手动：Integer i = Integer.valueOf(100); int n = i.intValue();
自动：Integer i = 100; int n = i;

自动装箱和自动拆箱是JDK 1.5引入的语法糖，编译器会自动把Integer i = 100翻译成Integer i = Integer.valueOf(100)，把int n = i翻译成int n = i.intValue()。看起来很方便，但方便背后有代价。

最大的代价就是性能。自动装箱会创建对象，如果在循环里频繁装箱拆箱，会产生大量临时对象，给GC增加压力。举个典型反面教材：

Integer sum = 0; for (int i = 0; i < 1000000; i++) { sum += i; // 每次循环：拆箱+加法+装箱，三万个对象就没了 }

这段代码里，sum是Integer，i是int。sum += i的实际执行过程是：sum.intValue() + i，得到int结果后又调用Integer.valueOf重新装箱。如果i超过127，new出来的对象数量就很吓人。实测跑一百万次循环，这种写法比直接用int慢好几倍。正确做法是循环里用基本类型，最后要存进集合时再装箱。

还有一个更隐蔽的坑是equals和==混用。两个Integer用==比较，比较的是引用地址，不是数值。这在下面第4节我会专门展开。

1.3 包装类里常用的核心API清单

每个包装类都有一组固定的“家族式”方法，搞懂一个，其他基本全会。核心方法分四类：

第一类是字符串到数字的解析方法，最典型的是Integer.parseInt(String)、Long.parseLong(String)、Double.parseDouble(String)。这类方法返回基本类型，输入不对会抛NumberFormatException。特别注意，Integer.parseInt("3.14")必挂，parseInt只认整数格式。

第二类是valueOf系列，不只是Integer.valueOf(int)，还有Integer.valueOf(String)。它返回包装类对象，内部有缓存机制（后面细聊）。如果你只需要基本类型，用parseInt就够了；需要对象就valueOf。

第三类是intValue、doubleValue这类拆箱方法，以及toString、equals、hashCode这些Object继承来的方法。特别提醒，包装类的hashCode不是简单返回底层数值，Integer的hashCode就是value本身，但Double的hashCode是value对应long的位模式再做一次异或右移运算，具体实现翻源码能看到。

第四类是进制转换的静态方法：toBinaryString、toHexString、toOctalString，以及Integer类特有的parseInt(String, radix)方法，可以指定进制解析，比如二进制字符串转十进制就是Integer.parseInt("1010", 2)，结果是10。

每个包装类还有几个常量值得记一下：Integer.MAX_VALUE是2147483647，Integer.MIN_VALUE是-2147483648，Integer.SIZE是32（位数），Integer.BYTES是4（字节数）。

2. 数学类不止是static方法——Math、Random与严格计算

2.1 从Math类开始：那些高频的静态方法

Math类从名字就能看出来，干的全是数学运算。它全篇都是static方法，不需要实例化，直接用Math.xxx()调用。日常开发中最高频的几类，我按使用频率排个序：

绝对值类：Math.abs(int/double/...)。注意一个极端情况：Math.abs(Integer.MIN_VALUE)的结果还是负数，因为int范围不对称，正数最大只到2147483647，取不到2147483648，溢出后绕回负数。这在做金额绝对值计算时非常危险。

最值类：Math.min、Math.max，支持基本类型，其实内部就是三元表达式，没啥性能损耗。日常写int max = a > b ? a : b和Math.max(a, b)完全等价，看个人喜好。

幂和根：Math.pow(a, b)、Math.sqrt(x)、Math.cbrt(x)。注意pow的两个参数都是double，返回值也是double。想算整数幂反而要小心，Math.pow(2, 10)返回的是1024.0，你要int的话还得自己强转或者加个epsilon再取整。

向上向下取整和四舍五入：Math.ceil(x)是向上取整找最小的整数（天花板），Math.floor(x)是向下取整找最大的整数（地板），Math.round(x)是四舍五入。这三个方向搞反的人很多，我直接给个对照表：

方法	Math.ceil(2.1)	Math.floor(2.9)	Math.round(2.5)	Math.round(-2.5)
结果	3.0	2.0	3	-2

注意负数的round：Math.round(-2.5)结果是-2，不是-3。因为round底层是floor(x + 0.5)，-2.5 + 0.5 = -2.0，floor(-2.0) = -2。要四舍五入到3这种数学上的对称行为？做不到，round就是原地+0.5下取整，和正负数无关，理解这个公式就不会记混了。

另外一个我特别想提醒的：Math类还有一个random()方法，但它不是数学运算，是随机数生成器，底层调用Random类的nextDouble()。这个单独在2.2节展开讲。

2.2 随机数别只会用Math.random()

很多人写随机数就只会Math.random()，这个方法返回[0.0, 1.0)的double，用起来确实简单，但在工程里并不总是最优选择。

先看Math.random()的参数缺陷。它只返回0到1之间的小数，你想要个[1, 100]的整数就得自己算：

int randomNum = (int)(Math.random() * 100) + 1; // 得到1~100

这个写法没问题，但可读性差。更关键的是，每一次Math.random()调用都要创建一次Random对象（源码里的方法是RandomNumberGeneratorHolder.randomNumberGenerator.nextDouble()，用的是ThreadLocalRandom的一个静态实例），高并发场景下性能不如直接用ThreadLocalRandom.current().nextInt(...)。

实战中生成随机整数的三个选择：

(int)(Math.random() * n) + min：需要手动处理边界，适合偶尔用一次
new Random().nextInt(bound)：传入一个上界，返回[0, bound)的整数，需要加min调整区间
ThreadLocalRandom.current().nextInt(min, max + 1)：多线程友好，写法最清晰，我最推荐这种方式

看一段实际用法：

// 抽奖活动：从1到1000之间抽一个奖品编号 ThreadLocalRandom random = ThreadLocalRandom.current(); int luckyNumber = random.nextInt(1, 1001); // 包含1，不包含1001，正好是1~1000

nextInt(origin, bound)方法的规则是：包含origin，不包含bound。这个规则容易记反，我当初也踩过几次坑：写nextInt(1, 100)的时候以为能抽到100，结果每次最高只有99。后来总结了一个口诀：左闭右开。

还有一个冷知识：Random类如果两个实例用相同种子（seed），生成的随机序列完全一样。这在测试环境很坑，比如你两个JVM进程同时new Random()，而系统时间恰好相同，两边的随机数就能对得上。生产环境一般没事，但做分布式任务时要注意种子一致性带来的“伪随机重复”问题。

2.3 BigDecimal：金额计算必须用它

有一句话我建议每个Java开发都刻在脑子里：double和float永远不要用于金额计算。别跟我说误差只有一点点，金额这种东西差一分钱都是事故。

为什么double会有误差？因为进制转换问题。十进制的0.1转成二进制是一个无限循环小数（0.000110011001100...），double精度只有52位尾数，存不下这么多位，只能截断。所以0.1 + 0.2在double里算出来是0.30000000000000004，不是0.3。这不是bug，是浮点数的宿命。

BigDecimal解决这个问题的思路是：不直接用二进制浮点数存储，而是用十进制的大整数加上一个scale（小数位数）来表示。比如123.45内部存储就是 unscaledVal = 12345, scale = 2，表示12345 × 10⁻²。

使用BigDecimal有四个核心注意点：

第一，构造方法要用String。new BigDecimal(0.1)你以为是0.1，实际存储的是0.1000000000000000055511151231257827021181583404541015625。因为传入的double参数本身就已经失真了。正确写法是new BigDecimal("0.1")。这是最经典的坑，没有之一。

第二，四则运算方法是add、subtract、multiply、divide，不是加减乘除运算符。

第三，除法必须指定精度和舍入模式。divide(BigDecimal divisor)这句代码在不整除的情况下会抛ArithmeticException: Non-terminating decimal expansion。所以要写divide(divisor, scale, RoundingMode.HALF_UP)。

第四，BigDecimal是不可变对象，加减乘除都会返回新的BigDecimal，原对象不变。

看一个安全的分摊场景：

BigDecimal total = new BigDecimal("100.00"); BigDecimal each = total.divide(new BigDecimal("3"), 2, RoundingMode.HALF_UP); // 结果是33.33，而不是报错或者33.3333...

这里scale取2是“分”的精度，RoundingMode.HALF_UP是四舍五入，符合绝大多数财务场景。

2.4 对数、指数与严格数学运算

除了上面这些，Math类还提供了全套的超越函数：Math.log(x)是自然对数（以e为底），Math.log10(x)是常用对数（以10为底），Math.exp(x)是e的x次幂。这类函数在算法类业务里更常见，比如计算信息熵、归一化指数（softmax）常需要log和exp配合。

顺带提一下StrictMath类。StrictMath和Math几乎一模一样，区别是StrictMath所有算法严格遵循IEEE 754标准，保证在不同平台上计算结果完全一致；Math为了性能允许使用平台相关的硬件指令，结果可能在不同平台有微小差异。绝大多数业务不需要这种跨平台的一致性，但如果做科学计算、加密算法、跨端同步计算，统一用StrictMath更稳妥。

还有个细节：Math类里的三角函数（sin、cos、tan）接收的单位是弧度（radian），不是角度。想算30度的正弦，得先转弧度：Math.sin(Math.toRadians(30))，结果是0.5。Math.toRadians和Math.toDegrees这两个转换方法也很常用，但很容易被忽略。

3. 综合案例：用包装类与数学类解决一个实际问题

3.1 场景设计：简化版订单统计工具

纯讲API很枯燥，我拿一个真实业务场景串一遍：一个订单统计功能。需求很简单，给你一个订单金额列表，需要计算出总金额、平均金额、最大金额、最小金额，并且按“元”为单位输出成两位小数的字符串。

很多人一上来就用double数组存金额，然后for循环累加。这也能跑，但只要金额一多、小数位一多，误差就会累积放大。正确做法是List加BigDecimal。

这个功能虽然简单，但它把本节所有知识点都能串起来：集合要用包装类、金额要用BigDecimal、比较大小要用compareTo而不是equals、格式化输出要setScale。

3.2 关键实现逐步拆解

先定义数据结构。因为金额进入集合，必须用List<BigDecimal>，这里BigDecimal既是数学类也是包装类的“近亲”——它就是为精确计算设计的数值类。

import java.math.BigDecimal; import java.math.RoundingMode; import java.util.ArrayList; import java.util.List; public class OrderStatistic { public static void main(String[] args) { List<BigDecimal> amounts = new ArrayList<>(); amounts.add(new BigDecimal("19.90")); amounts.add(new BigDecimal("299.00")); amounts.add(new BigDecimal("0.80")); amounts.add(new BigDecimal("99.00")); amounts.add(new BigDecimal("1500.50")); // 1. 求和：累加时注意不可变性 BigDecimal sum = BigDecimal.ZERO; for (BigDecimal amount : amounts) { sum = sum.add(amount); // add返回新对象，必须重新赋值 } // 2. 最大最小值：先拿第一个做基准，再逐一比较 BigDecimal max = amounts.get(0); BigDecimal min = amounts.get(0); for (int i = 1; i < amounts.size(); i++) { BigDecimal current = amounts.get(i); if (current.compareTo(max) > 0) { max = current; } if (current.compareTo(min) < 0) { min = current; } } // 3. 平均值：除法必须指定scale和舍入模式 BigDecimal avg = sum.divide(new BigDecimal(amounts.size()), 2, RoundingMode.HALF_UP); // 4. 格式化输出：保留两位小数，四舍五入 System.out.println("订单数：" + amounts.size()); System.out.println("总金额：" + sum.setScale(2, RoundingMode.HALF_UP)); System.out.println("平均金额：" + avg); System.out.println("最高金额：" + max); System.out.println("最低金额：" + min); } }

这段代码有几个细节值得展开讲讲：

第一个：求和用的是sum = sum.add(amount)，而不是sum.add(amount)。BigDecimal是不可变对象，add方法是返回一个新的BigDecimal，不修改原来的sum。这个坑新手几乎必踩，写完才发现sum一直是0。

第二个：比较大小用的是compareTo方法，不是equals。BigDecimal的equals有点“矫情”，它认为2.0和2.00不是同一个对象，因为scale不同；而compareTo认为它们在数值上相等。业务上判断金额相等应该用compareTo == 0，别用equals。

第三个：平均数是divide除法，必须给scale和RoundingMode。这里有5个订单合计1919.20，除以5等于383.84，刚好整除，所以没报错。但如果换成4个订单，1919.20 / 4是479.8，还是不报错。真正危险的是除不尽的场景，比如3个订单分100块钱，不指定scale和模式就直接抛异常了。

3.3 答案是整数还是小数？拆箱与装箱要注意的边界问题

在统计功能里，amounts.size()返回的是int类型，new BigDecimal(amounts.size())这里就是把int自动装箱成Integer，再通过Integer和BigDecimal的构造函数转换。这个过程中，int先被装箱成Integer对象，再被拆箱成int值传入构造器，虽然最终结果一样，但多了一次无意义的装箱拆箱。更优雅的写法是BigDecimal.valueOf(amounts.size())，valueOf内部会直接处理int和long类型，不产生中间对象。

另一个边界问题：订单数用int够不够？如果系统日订单量超过21亿，int就溢出了，得用long。我见过很多系统上线几年后订单量到了int上限，统计模块直接算错。设计阶段就把订单数声明为long，或者用Integer.MAX_VALUE做上限判断，能省掉后面一堆麻烦。

3.4 随机数的工程应用：红包金额生成器

再完整写一个抽奖/红包场景。假设要做个活动：生成一个1到200元之间的随机红包金额，要求保留两位小数。这个场景要用到随机数和BigDecimal配合，也是很多初学者的盲区：随机数直接生成double然后new BigDecimal，会有精度问题。

import java.math.BigDecimal; import java.math.RoundingMode; import java.util.concurrent.ThreadLocalRandom; public class LuckyMoney { public static void main(String[] args) { for (int i = 0; i < 5; i++) { BigDecimal amount = randomAmount(1, 200); System.out.println("红包金额：" + amount); } } private static BigDecimal randomAmount(int min, int max) { ThreadLocalRandom random = ThreadLocalRandom.current(); // 生成100到20000之间的整数，代表“分” int cents = random.nextInt(min * 100, max * 100 + 1); // 用整数构造BigDecimal，再除以100得到“元” return BigDecimal.valueOf(cents, 2); } }

这个实现的关键思路是：先把金额换算成“分”（整数），在整数范围内做随机，最后再用BigDecimal精确构造。整数运算是精确的，随机也精确，最后一步valueOf(cents, 2)直接把整数值除以100，没有任何浮点误差。这是处理随机金额的正确姿势，比先生成double再四舍五入稳得多。

4. 我这几年踩过的坑——常见问题与排查技巧

4.1 Integer比较等不等于？Cache缓存机制深度扒皮

这个坑出现频率极高，我直接给测试题：

Integer a = 100; Integer b = 100; System.out.println(a == b); // true Integer c = 200; Integer d = 200; System.out.println(c == d); // false

为什么第一个是true第二个是false？因为Integer的valueOf(int)方法内部有缓存：默认缓存了-128到127之间的Integer对象实例。当你装箱的int值落在这个区间内，valueOf直接返回缓存池里的同一个对象；超出区间就new一个新对象。

所以a和b拿的是同一个对象引用，==为true；c和d是两个不同对象，==比较引用地址，自然false。这个设计是为了性能优化：-128到127的整数使用频率最高，复用对象能减少内存分配。类似机制也存在于Character（0~127）、Short（-128~127）、Long（-128~127）中。Double和Float没有缓存，因为浮点数“值”太离散，缓存意义不大。

排查这个问题的标准方案是：所有包装类对象比较，一律用equals或者compareTo，不要用==。==在[-128, 127]区间碰巧成立，给了很多人“==也能用”的错觉，一旦数值跨过127就翻车。

4.2 BigDecimal的equals和compareTo之争

我刚才提到new BigDecimal("2.0").equals(new BigDecimal("2.00"))结果是false，但compareTo是0。这个差异在Set和Map里尤其致命：如果你用BigDecimal做HashMap的key，HashMap用equals和hashCode来判断key是否重复，那么2.0和2.00会当成两个不同的key，看似相同的金额却存了两条记录。而用HashSet存储时也会出现重复元素。

解决方案：如果业务上认为2.0和2.00是等价的，就别用BigDecimal直接做Map的key，或者在处理数据前先把所有BigDecimal统一scale到同一精度（比如都setScale(2)），这样equals和hashCode也一致了。

4.3 除法不指定舍入模式，直接crash

我在3.2节里特意强调过，说少了都是泪。有一次我在生产环境跑一个佣金结算的任务，逻辑是佣金 = 总额 / 单数。运营那边配了一组3单的数据，总额是100元，100/3=33.333...，无限循环。BigDecimal的divide方法默认有精度限制，除不尽就抛异常，整个任务直接挂掉。日志里就是ArithmeticException，排查了半天才反应过来是divide的问题。

修复方案就是必写两参数：divide(divisor, scale, RoundingMode.HALF_UP)。scale根据自己的业务定，金额类一般到2（分），汇率类可能需要4-6位。RoundingMode.HALF_UP是最常用的四舍五入，但有些场景比如库存、张数，可能有自己特定的舍入逻辑，得按需选。

4.4 包装类和基本类型的NPE问题

自动拆箱最大的隐患是NPE（空指针异常）。看一个经典场景：

Integer value = null; int result = value + 1; // 运行期抛 NullPointerException

value是Integer对象，和int相加时要拆箱，调用value.intValue()，而value是null，调用方法直接NPE。这种错误在从数据库/接口取值，拿到null后直接参与运算时尤其常见。

排查技巧：凡是包装类参与运算、比较、拼接前，务必判空。if (value != null)是最保险的。另外Java 8的Optional在null语义管理上能帮上忙，但这属于另一个话题了。

4.5 Random种子重复导致线上随机结果一致

这是一个比较少见的坑，但遇到就非常诡异。当年做一个A/B测试分流服务，用new Random()生成实验组ID，结果上线后一连几次实验组比例都异常。查到最后发现：服务由多个节点组成，每次重启时系统时间恰好相同（比如都是整点启动），new Random()的种子来自当前纳秒时间，如果两个节点启动时间差距太小，种子可能撞上，两个节点生成相同的随机序列，导致分流不均。

解决方案是用ThreadLocalRandom.current()，它内部维护的是线程级的种子更新，每个线程独立，不容易出现全局重复序列。或者显式指定一个业务相关的种子，比如基于用户ID做seed，这样同一个用户每次进来分到的随机结果反而是一致的（有状态随机）。

4.6 包装类作为Map key时的哈希性能

最后说一个偏性能的坑。如果Map的key是Integer，HashMap计算哈希时直接取value本身，速度很快。但如果是Long或者String，哈希算法会多几步位运算。这在数据量千万级以上才看得出差异，平时不用过度担心。真正要小心的是：同一个对象作为key时，它的hashCode计算依赖内部状态，如果对象可变，哈希值也会变，Map就找不到之前放的键了。包装类都是不可变的，所以不存在这个问题，这也是为什么推荐用包装类做key而不是自定义可变对象。