企业官网建设流程全解析

搞Java开发这些年，我见过不少人把“常用类”这一章草草翻过去——String类天天在用，看得仔细；包装类和Math类觉得没什么可看的，就是几个静态方法嘛。真到写代码、排查线上问题时才发现，坑全埋在“简单”下面。包装类涉及自动装箱、缓存、空指针、相等比较这些日常高频问题，Math类则是随手调用的数学工具箱，用对了省事，用反了出事故。这篇文章我就以第13章这两个主题为线索，把包装类和数学类的核心机制、高频用法、常见坑位一次说清楚，适合正在学JavaSE基础的同学，也适合准备面试或者写工具类时翻出来对照。

1. 包装类：先理解“int为什么要有对象”这件事

1.1 为什么需要包装类，它们和基本类型的对应关系

Java有8种基本类型，但它们不是对象，不能放进泛型容器，也不能调用方法。与此同时，集合框架（List、Map、Set这些）要求元素必须是Object的子类，泛型擦除后也不支持基本类型。这两套体系是割裂的，为了打通它们，JDK为每种基本类型都配了一个对应的类，这些类统称为包装类。

对应关系很简单：

注意两个特别的名字：int对应Integer，char对应Character，其他六个都是基本类型名首字母大写。这个表值得背下来，因为包装类默认值是null这一点，决定了它和基本类型最本质的区别：基本类型永远有值，包装类能表达“没有值”或“尚未设置”的状态。

实际开发中这个差异非常关键。比如数据库某个字段允许为空，映射到Java实体里如果定义成int，查询出来会自动填0，用户明明没设置过，页面却显示0，容易产生误导。定义成Integer则能拿到null，前端就知道这个字段没有值，该隐藏隐藏、该提示提示。JSON返回给前端的时候，Integer是null会输出null，int则会输出0，很多联调问题就是从这里开始的。

1.2 自动装箱与拆箱：编译器的“隐形代码”

JDK 5之后，Java支持自动装箱和自动拆箱，写起来很爽，但很多人没搞懂底层发生了什么。

比如这一行：

Integer n = 42;

编译器会自动把它翻译成：

Integer n = Integer.valueOf(42);

这就是自动装箱，基本类型变成了包装类对象。

反过来的情况：

int sum = n + 1;

编译时会变成：

int sum = n.intValue() + 1;

这就是自动拆箱，包装类对象变回基本类型。

问题在于，拆箱过程是编译器悄悄帮你加了一句xxxValue()调用。如果这个包装类是null，调方法时就会抛NullPointerException。看这个经典例子：

Integer total = null; int sum = total + 1; // 运行到这里直接NPE

一眼看上去是简单的加法，但实际上这里发生了total.intValue()调用，total是null，直接崩了。我当年做电商优惠券计算时就踩过这种坑，数据库里优惠金额字段是NULL，取值出来放进Integer，一参与四则运算，线上接口就报错，日志里看堆栈全是NullPointerException，定位起来还挺费劲。

所以记住一句话：自动拆箱的前提是包装类不为null，参与运算或赋值给基本类型之前，务必判空。

2. 包装类核心用法与高频方法拆解

2.1 字符串转换：parseXxx和valueOf怎么选

项目里大量需求是把字符串数字转换成真正的数字类型，比如从表单、请求参数、配置文件里读到的都是String，用之前必须转类型。包装类提供了静态转换方法，最常用的两组是parseXxx和valueOf：

int a = Integer.parseInt("123"); // 返回基本类型 int Integer b = Integer.valueOf("123"); // 返回包装类 Integer double d = Double.parseDouble("3.14"); boolean flag = Boolean.parseBoolean("true");

parseInt返回的是基本类型int，后面直接用于数值计算没压力；valueOf返回的是包装类Integer，更适合放进集合或者作为对象传递。Java 9以后还有个Integer.valueOf(String)的兄弟Integer.parseInt(String)，底层实际调用parseInt再装箱，这个细节知道就行。

这里真正的坑是格式敏感。字符串只要混有非数字字符，转换就会抛NumberFormatException。我遇到最多的情况有两种：

第一种是字符串带空格，比如" 123"，直接parse会炸，必须先trim()。

第二种是带了千分位分隔符，比如"1,200"，parse也会炸，需要先去掉逗号再转换。

实际项目中我通常写一个小工具方法，统一处理这些脏数据：

public static int toInt(String value, int defaultValue) { if (value == null) { return defaultValue; } try { return Integer.parseInt(value.trim().replace(",", "")); } catch (NumberFormatException e) { return defaultValue; } }

这样调用方就不需要每个地方都try-catch，还统一了缺省值逻辑。

2.2 Integer缓存机制：小数字的“户口本”

这是面试高频，也是线上bug高发区。Integer内部维护了一个缓存池IntegerCache，默认缓存范围是-128到127，也就是说在这个区间内的整数，valueOf返回的是同一个对象。

Integer a = 100; Integer b = 100; System.out.println(a == b); // true，两个引用指向同一个缓存对象 Integer c = 200; Integer d = 200; System.out.println(c == d); // false，超出缓存区间，创建了两个新对象

很多人第一次看到这个结果会觉得“Java神经病啊”，但这是经过权衡的设计。小整数对象在业务代码里出现频率极高，缓存起来可以减少对象创建，提升性能。问题在于，不少人把==当成了数值比较来用，结果运行环境一变，结果就变了，很难复现。

Long也有类似的缓存范围-128到127，Character缓存0到127，Byte和Short因为范围本身小，整个范围都缓存了。

结论很明确：比较包装类的数值，永远用equals()，或者先拆箱再比较，千万别用==。哪怕你确认现在在缓存区间内，也别依赖这个行为，JVM参数-XX:AutoBoxCacheMax是可以调整缓存上限的，代码一旦依赖这种实现细节，就是给自己埋雷。

2.3 equals方法：包装类比较只能有一种正确姿势

==比较引用，equals比较数值，这是包装类最基础也最容易混淆的点。更隐蔽的是，equals还要求类型一致：

Integer.valueOf(1).equals(Long.valueOf(1)); // false

数值相等但类型不同，equals返回false。在写通用工具类的时候，这种比较很容易踩坑，比如从Map里拿值，一会儿Integer一会儿Long，直接equals对不上，先打印日志一看数值明明一样，找了半天才发现是类型问题。

我自己的习惯是，凡涉及Integer和int比较，直接让基本类型参与运算；凡涉及两个包装类比较，统一用equals，特别是两个都是null的情况，equals返回true，行为是合理的：

Integer x = null; Integer y = null; System.out.println(x == null ? y == null : x.equals(y)); // true

另外，推荐一种防NPE写法：把常量放前面调用equals。

if (Integer.valueOf(1).equals(status)) { // 即使status是null，这里也不会抛空指针，equals返回false }

反过来status.equals(Integer.valueOf(1))在status为null时直接NPE。这个细节我在code review时经常提，成本极低收益不小。

至于Character和Boolean这两个相对“轻量”的包装类，实际开发中常用方法不多，但有几个很实用：

Character.isDigit('5'); // 判断是否是数字 Character.isLetter('a'); // 判断是否是字母 Character.isWhitespace(' '); // 判断是否是空白 Boolean.parseBoolean("true"); // 字符串转布尔

处理验证码、输入合法性校验时，Character这几个静态方法很有用，不用自己写正则。

3. 数学类Math：一个全是静态方法的工具箱

3.1 那些每天都在用的Math方法，边界情况你想过吗

Math类的构造方法是private的，官方设计就是不让你new，所有方法都是静态的，直接Math.xxx()调用。它最常用的几个方法如下：

几个边界情况值得专门提出来：

第一，Math.abs(Integer.MIN_VALUE)返回的是-2147483648，依然是负数。因为int的范围是-2147483648到2147483647，绝对值2147483648超出了int能表示的范围，溢出后还是负数。如果你要取绝对值的是int最小值，要么转成long再取，要么用Math.abs((long) val)。

第二，Math.round对负数的处理很容易误解。它内部实现是Math.floor(x + 0.5)，所以：

Math.round(-1.5); // 结果是-1，不是-2 Math.round(-1.6); // 结果是-2

负数时“四舍五入”其实变成了“先四舍五入再向负无穷取整”，这里非常容易算错。

第三，Math.pow返回double，大量涉及整数的幂运算时要注意精度，比如Math.pow(2, 10)算出来是1024.0，如果你要的是int，直接强转没问题；但如果算Math.pow(5, 3)这类结果再和别的浮点数硬比较，就可能因为浮点误差翻车。需要精确结果的场景，用整数循环或BigDecimal，别依赖pow。

3.2 随机数：Math.random和Random、ThreadLocalRandom怎么选

Math.random()是最早接触的随机数写法，返回[0.0, 1.0)范围内的double。但它内部使用了一个静态的Random实例，多线程高并发调用时会有竞争和性能问题，而且拿到的double再缩放成整数区间，写法也很别扭。

JDK 7之后，官方推荐用ThreadLocalRandom，每个线程维护独立的随机种子，没有锁竞争，性能和线程安全性都比直接new Random好：

// 生成 [1, 100] 的随机整数 int num = ThreadLocalRandom.current().nextInt(1, 101); // 生成 [0, 33) 的随机整数 int idx = ThreadLocalRandom.current().nextInt(33);

要是只是生成一个随机数，写在业务方法里就直接用ThreadLocalRandom，别new Random()。但有一种场景需要保留Random，就是用固定种子复现随机序列，比如测试、模拟实验，new Random(42L)可以保证每次运行生成的序列完全一致，方便排查问题。

安全性上多说一句：Random和Math.random()都不适合做安全相关的随机数生成，它们不是加密安全随机数，抽奖、Token、验证码这类场景如果要求防预测，要用SecureRandom。普通负载均衡随机、随机选取数据这类不涉及安全的场景，ThreadLocalRandom足够。

4. 实操：用包装类与Math类实现一个随机号码生成器

4.1 需求分解：生成双色球号码并格式化输出

只看理论容易飘，不如写个小工具把前面这些知识点串起来。假设产品提了一个需求：生成一组随机双色球号码，红球6个（范围1到33，不能重复），蓝球1个（范围1到16），输出时每个号码补零到两位，红球按升序排列。

先拆解一下需要什么：

• 生成随机数，用ThreadLocalRandom。
• 保证红球不重复，最直观的做法是每次随机一个数然后去重判断，但要循环重试，效率不高。
• 更好的思路是用洗牌法：把1到33放进一个列表，随机打乱顺序，取前6个，再排序。这样天然不重复，也不用反复重试。
• 格式化输出补零，用String.format("%02d", num)。

4.2 代码实现与逐段解读

import java.util.ArrayList; import java.util.Collections; import java.util.List; import java.util.concurrent.ThreadLocalRandom; public class RandomLottery { private static final int RED_MAX = 33; private static final int RED_COUNT = 6; private static final int BLUE_MAX = 16; public static void main(String[] args) { List<Integer> redBalls = generateRedBalls(); int blueBall = ThreadLocalRandom.current().nextInt(1, BLUE_MAX + 1); System.out.println("红球: " + formatNumbers(redBalls)); System.out.println("蓝球: " + formatNumbers(List.of(blueBall))); } private static List<Integer> generateRedBalls() { List<Integer> pool = new ArrayList<>(); for (int i = 1; i <= RED_MAX; i++) { pool.add(i); } Collections.shuffle(pool); List<Integer> selected = new ArrayList<>(pool.subList(0, RED_COUNT)); Collections.sort(selected); return selected; } private static String formatNumbers(List<Integer> numbers) { StringBuilder sb = new StringBuilder(); for (int num : numbers) { if (sb.length() > 0) { sb.append(" "); } sb.append(String.format("%02d", num)); } return sb.toString(); } }

几个关键点逐一说：

Collections.shuffle(pool)用的是默认随机源，内部已经处理好了随机性，比自己写随机去重清晰得多。洗牌后pool.subList(0, RED_COUNT)取前6个，但要注意subList返回的是原列表的一个视图，不是独立副本。在这里后续不会修改pool，所以直接使用问题不大，但更稳妥的做法是像代码里那样包一层new ArrayList<>()，切断和原列表的关联，避免以后有人改了pool影响到取出来的结果。

ThreadLocalRandom.current().nextInt(1, BLUE_MAX + 1)的区间是左闭右开，所以生成1到16的随机数要写成nextInt(1, 17)，很多人第一次用会写错成nextInt(1, 16)，结果永远拿不到16。

String.format("%02d", num)是格式化补零的好帮手，两位整数，不足两位前面补0，输出效果就是“01 05 12 23 28 33”。

循环里for (int num : numbers)有个自动拆箱的过程，这里安全，因为numbers列表里不可能放null，集合元素是Integer但赋给基本类型int变量时编译器自动拆箱，不会触发异常。

4.3 扩展：如果要判断中奖，包装类比较的坑就来了

假设进一步要做一个中奖判断，输入一组用户号码，和开奖号码比对。最朴素的写法：

List<Integer> userBalls = parseUserInput("01 05 12 23 28 33"); int redHit = 0; for (Integer userBall : userBalls) { if (redBalls.contains(userBall)) { redHit++; } }

这里contains底层走的是equals，因为Integer重写了equals，比较的是数值，所以功能上没问题。但如果你图省事用for循环里直接写userBall == redBalls.get(i)，就踩中了前面说的引用比较问题，号码在缓存区间内没事，一旦超出范围，结果就飘了。

另一个容易翻车的地方是parseUserInput，用户输入“01 05 12 23 28 33”这种字符串，如果直接Integer.parseInt("01")是可以的，结果是1，没问题；但如果用户输入带其他空白，或者某个号码漏了空格，就会抛异常，需要在解析时做好容错。

之前遇到过生产环境的一个类似问题：用户输入字符串用逗号分隔，代码用split(",")，但用户在中文输入法状态下输成了全角逗号，split直接不识别，解析结果数组只有一项，后面的判断全错。所以解析外部输入，一定要先做标准化，把全角标点转半角、去掉所有空格，再走解析逻辑。

这个小工具写下来，包装类的自动拆箱、equals比较、ThreadLocalRandom随机数、格式化补零，全用上了。日常很多工具类本质上就是把这类知识点组合起来，多写几次自然就熟了。

5. 常见问题与排查技巧实录

5.1 包装类空指针：线上最常见的“隐形杀手”

包装类空指针之所以“隐形”，是因为代码看起来没有任何问题。Integer count = map.get("count");明明是个赋值语句，谁能想到下一行count++就炸了呢？

常见场景有三种：

第一种，从数据库查出的字段映射到Integer属性，数据库里字段为NULL，代码直接做算术运算。

第二种，从JSON解析的实体对象，前端没传某个Integer字段，后端拿到一个null的包装类，到处参与比较。

第三种，方法返回类型是Integer，内部逻辑某条路径返回null，调用方直接把这个结果赋给int变量，拆箱NPE。

排查思路有两条：

一是看异常堆栈。如果堆栈里出现Integer.intValue()或者Long.longValue()这类方法调用，基本上就是自动拆箱触发的空指针。IDE里断点也很方便，直接看变量值是不是null。

二是写代码时规范起来。实体字段能定义成基本类型就定义成基本类型，确有必要用包装类的地方，比如数据库可空字段、集合泛型元素，用之前先判空。

5.2 性能损耗：包装类是对象，创建和缓存要留意

包装类本质是对象，每次new一个都会产生堆内存分配。虽然JVM对短生命周期对象有优化，但高频循环里还是能感觉到差异。比如：

for (int i = 0; i < 1000000; i++) { Integer value = i; // 每次循环都会装箱，超出缓存区间还得new对象 }

这种代码应尽量避免，能直接用int就用int。集合里必须用包装类时没办法，但操作时尽量先拆箱再计算：

List<Integer> prices = getPrices(); int total = 0; for (int price : prices) { // 循环内部只拆箱一次，没有额外的装箱操作 total += price; }

这段代码里for (int price : prices)自动把Integer拆箱成int，total是基本类型，整体没有额外装箱，性能损耗很小。如果反过来用Integer total = 0然后在循环里total += price，每次都会装箱拆箱，一万次循环还好，百万次循环差距就出来了。

5.3 数学类高频易错点速查表

这张表基本覆盖了我这些年遇到过的“回头翻文档”时刻。每一项都有人踩过，踩的时候都很怀疑人生，因为结果和直观预期完全不一致。

最后再分享一个我自己的习惯：实体字段能不用包装类就不用，尤其ID和数字状态这种字段，int比Integer少很多空指针问题；但凡是数据库可空字段、或者要放进集合里的数字，才用包装类。所有包装类数值比较，统一走equals，两份代码都判了null再比基本类型也省心。随机数生成优先ThreadLocalRandom，别在循环里new Random。第13章这两个类看着基础，真把这些边界抠清楚，后面学集合、泛型、IO时会少踩很多莫名其妙的坑。把坑提前踩完，比等线上出事故再回头翻文档，要划算得多。