企业官网建设流程全解析

1. 为什么单独给"字符串数组转List<Integer>"写一篇实战

坦白说，这个需求看起来简单到不值一提，但我在实际工作中发现，它几乎是每个Java开发者入职后第一个月就会踩到的坑。你从接口拿到String[]形式的ID列表，数据库查询却需要List<Integer>；你从前端表单接收逗号分隔的字符串，后端实体类却定义的是List<Integer>属性；你从配置文件读取一批数字，业务逻辑却要求做整数集合运算。诸如此类，全都要过"字符串数组转List<Integer>"这一关。

Java 8引入的Stream API是解决这类集合转换问题的首选工具，因为它把"遍历-转换-收集"三个动作压缩成一行代码，可读性比传统for循环高一个档次。但Stream不是万能的，它有自己的生命周期规则、装箱开销、异常处理盲区，用不好同样会翻车。这篇博文我会从最朴素的for循环写法讲起，再拆解Stream方案，最后把边界情况、性能陷阱、实战坑位一一铺开，配套完整的代码示例和排查思路。

适合谁看？初级开发者想把集合操作从"能跑"提升到"写得规范"，中级开发者想系统梳理Stream的细节和坑点，甚至高级开发者在code review时想给出更有说服力的改进建议，这篇文章都能提供参考。我不写教科书式的API罗列，只讲实际项目中真正用得上、真正容易出错的东西。

2. 基础方案：传统循环写法与它的局限性

2.1 最朴素的for循环实现

不借助Stream，最直接的写法是这样：

String[] ids = {"1", "2", "3", "4", "5"}; List<Integer> idList = new ArrayList<>(); for (String id : ids) { idList.add(Integer.valueOf(id)); }

逻辑没有错，代码也能跑。但对于习惯了函数式编程风格的人，这个写法有几个明显的不足：第一，idList需要提前声明并new出来，属于"命令式"的样板代码；第二，循环体的职责不止是转换，还隐含着"往集合里塞元素"这个动作，可读性一般；第三，如果后续还要做过滤、去重、排序，循环会越来越长，代码会逐渐变臭。

如果你用传统的Arrays.asList配合循环，还会遇到另一个经典问题：Arrays.asList返回的List是定长的，不能add也不能remove，很多人第一次在这上面栽跟头。

2.2 传统方案在复杂场景下的窘境

举个例子，假设你从外部接口拿到一批字符串，其中混着空串、空白字符、非数字内容，你希望转换时自动忽略这些脏数据。用for循环写：

String[] raw = {"1", " 2 ", "", "3a", null, "4"}; List<Integer> result = new ArrayList<>(); for (String s : raw) { if (s == null) { continue; } String trimmed = s.trim(); if (trimmed.isEmpty()) { continue; } try { result.add(Integer.valueOf(trimmed)); } catch (NumberFormatException e) { // 忽略非数字 } }

再看Stream版本：

List<Integer> result = Arrays.stream(raw) .filter(s -> s != null && !s.trim().isEmpty()) .map(s -> Integer.valueOf(s.trim())) .filter(this::isValidNumber) // 配合正则或try-catch包装 .collect(Collectors.toList());

Stream版本把"过滤null和空白"、"去空格"、"转整数"、"跳过非法值"变成了流水线上的四个独立环节，每一环的职责一目了然。调试时你可以随时在某一步peek进去看中间结果，这在循环写法里很难做到——你得临时加打印语句、改循环结构，非常痛苦。

还有一点容易被忽略：for循环写多了，程序员会不自觉地把所有逻辑塞进一个循环体里，形成"面条代码"。Stream天然的链式结构会提醒你把不同操作拆开，从编码习惯层面减少代码腐化的概率。

3. Stream核心方案：从代码到原理的完整拆解

3.1 一行代码实现转换的正确姿势

直接给结论，最常用的写法有两种：

// 写法一：用 map 手动处理异常 String[] arr = {"10", "20", "30"}; List<Integer> list = Arrays.stream(arr) .map(Integer::valueOf) .collect(Collectors.toList()); // 写法二：用 mapToInt 然后装箱 List<Integer> list2 = Arrays.stream(arr) .mapToInt(Integer::parseInt) .boxed() .collect(Collectors.toList());

Arrays.stream(arr)产生Stream<String>，这是起点。Integer::valueOf是方法引用，等价于lambda表达式 s -> Integer.valueOf(s)，把字符串解析成包装类Integer。collect(Collectors.toList())负责把Stream里的元素攒成一个List。整个过程没有显式的循环变量，没有集合声明。

我建议优先使用Integer::valueOf而不是Integer::parseInt配合boxed()。原因后面细说，简单提一句：valueOf本身返回Integer，不需要额外的装箱步骤，语义也更直白。但如果你的业务后续要基于int做数值计算，mapToInt得到的IntStream反而更方便，因为它自带sum()、average()、max()等数值聚合方法。

3.2 map与mapToInt的区别：不只是性能差异

流行说法是"mapToInt能避免装箱，性能更好"，这个说法对，但不完全。真正理解这两者的区别，要从Stream的泛型机制说起。

Stream<Integer>的元素类型是引用类型，每个元素都是一个Integer对象。如果你把一个String通过map(Integer::valueOf)转成Integer，Stream内部仍然是引用类型流，元素还是堆上的对象。而mapToInt返回的是IntStream，元素是基本类型int，直接存储在原始数组或专用容器里，不经过装箱。

批量转换场景下，mapToInt的收益是实打实的：假设你有10万个字符串要转，map方案会产生10万个Integer对象，mapToInt方案不会。但如果你最终要collect(Collectors.toList())，IntStream又必须调用boxed()把int装回Integer，装箱那一瞬间的代价又回来了。所以单看"字符串数组转List<Integer>"这个需求，两者性能差距并不大，选哪个更多是代码意图的差别。

真正的性能差异出现在"转完还要做数值计算"的场景：

// 需求：字符串数组转List<Integer>，并且求最大最小值、总和 String[] scores = {"90", "85", "95", "88"}; IntStream intStream = Arrays.stream(scores) .mapToInt(Integer::parseInt); int sum = intStream.sum(); int max = intStream.max().orElse(0);

这里IntStream的优势完全释放：求和、求最大最小都是专门针对基本类型的实现，既不产生包装对象，又省去迭代器的间接开销。反过来如果你一开始就用map转成Stream<Integer>，再做求和就得反复拆箱，写起来也别扭。

顺带提一个面试常问的细节：Integer::parseInt返回int，Integer::valueOf返回Integer。在mapToInt里只能用parseInt（因为需要int），在map里两者都能用（因为valueOf直接给Integer，parseInt会被自动装箱）。我之前见过有人把mapToInt(Integer::valueOf)写进代码，编译器其实不会报错——自动拆箱帮你兜底了，但这属于隐式转换，建议不要这么写，明确用parseInt更符合意图。

4. 边界情况与异常处理：Stream方案最容易翻车的地方

4.1 空字符串、空白字符和脏数据怎么处理

真实业务里，字符串数组几乎不可能干干净净全是合法数字。最常见的数据形态是这样的：

String[] input = {"1", " 2 ", "", null, "3", "abc", "4", "5 "};

如果直接跑Arrays.stream(input).map(Integer::valueOf)，至少会触发两个异常：Integer.valueOf(null)会抛出NumberFormatException（因为valueOf方法内部尝试解析null.toString()时直接炸掉），Integer.valueOf("abc")同样抛NumberFormatException。整个Stream在这一步就中断了，后面的元素全部丢失。

所以规范的写法必须在转换前做过滤，并且在转换时捕获异常。推荐两种策略。

策略一：过滤+正则校验，明确拒绝非法值：

List<Integer> numbers = Arrays.stream(input) .filter(Objects::nonNull) .map(String::trim) .filter(s -> !s.isEmpty()) .filter(s -> s.matches("-?\\d+")) // 支持负整数 .map(Integer::valueOf) .collect(Collectors.toList());

策略二：利用封装函数吞掉异常：

private Integer tryParse(String s) { if (s == null) { return null; } try { return Integer.valueOf(s.trim()); } catch (NumberFormatException e) { return null; } } List<Integer> numbers = Arrays.stream(input) .map(this::tryParse) .filter(Objects::nonNull) .collect(Collectors.toList());

我推荐第二种，原因很实际：正则匹配matches其实有一定性能开销，而且字符串形态复杂时（比如带正号、带前导零、带千分位分隔符）正则容易漏判或误判。tryParse的做法把"能否解析"的判断完全交给JDK自带的解析逻辑，可靠性最高。代价是多了一次装箱（返回null或Integer），但在这个场景下可以忽略。

4.2 空数组、null数组和超大数值该怎么办

空数组转出来的List是空List，这没问题。但数组本身就是null呢？Arrays.stream(null)直接抛NullPointerException。在动手之前先判空几乎成了行业共识：

if (arr == null || arr.length == 0) { return Collections.emptyList(); }

还有一个很多人忽视的点：字符串里的数字可能超出Integer范围。比如"2147483648"，这是int最大值加1，Integer.valueOf会抛NumberFormatException。如果你希望这类超界数字自动转成long或者被静默忽略，需要自己设计策略。行业里常见的做法是捕获异常后往下传递，或者配合正则限制位数（-?\\d{1,10}）来提前拦截。

另外，Collectors.toList()返回的可变List是ArrayList，允许包含重复元素，允许为null（只要你在收集前没过滤干净）。如果你需要去重，要在收集前调用distinct()：

List<Integer> uniqueNumbers = Arrays.stream(arr) .filter(Objects::nonNull) .map(String::trim) .filter(s -> !s.isEmpty()) .map(Integer::valueOf) .distinct() .collect(Collectors.toList());

distinct()放在map之后是为了避免对原始字符串做字符串比较（性能略差且语义不对），放在map之后对Integer比较是天然正确的。

5. Stream机制剖析：为什么它能"一次遍历"完成所有事

5.1 Stream的惰性求值：链式调用的执行时机

很多初学者以为map、filter会立刻把每个元素处理一遍，其实完全不是。Stream中间操作（filter、map、distinct、sorted）都是惰性的——它们只是记录了操作步骤，只有遇到终端操作（collect、forEach、reduce、count）时才会真正开始遍历。

说得直白点，你写了：

Arrays.stream(arr) .filter(s -> !s.isEmpty()) .map(Integer::valueOf) .collect(Collectors.toList());

这行代码实际的执行顺序是：从数组第一个元素开始，先问filter"这个元素留下吗"，留下才递给map做转换，转换结果塞进最终List，然后处理下一个元素。这是一种流水线模式，每个元素只被读取一次，每一步操作依次经过。这也是为什么中间操作可以无限串联——只要没有终端操作，它们什么都不会做。

这个机制有个实用推论：你可以把Stream的构建和消费拆开，构建阶段完全不影响性能，消费阶段才真正花时间。比如在一个方法里构建Stream并返回，调用方消费时才开始计算。这在写工具类时非常有用。

5.2 Stream的一次性：为什么不能复用同一个Stream

Stream是一次性消费品，这一点几乎每个用过的人都被坑过。看代码：

Stream<String> stream = Arrays.stream(arr); long count = stream.count(); List<Integer> list = stream.map(Integer::valueOf).collect(Collectors.toList());

第二行执行完，Stream已经被消费关闭了，第三行再调用会直接抛IllegalStateException: stream has already been operated upon or closed。这不是bug，是设计如此——Stream代表的是"对数据源的一次遍历过程"，遍历结束，过程随之终止。

如果确实需要两次消费同一个数据源，要么重新创建Stream（Arrays.stream(arr)很便宜，本质上只是封装了数组），要么把中间结果保存成List再复用。我的习惯是：只要不确定后续还会不会用，就先把Stream collect成List，后续操作基于List重新建流，这样既安全又清晰。

还有一个隐藏的坑：某些Stream数据源（比如Files.lines打开的I/O流）消费完必须关闭，否则会占用文件句柄。字符串数组这种内存数据源没有这个问题，但如果你的数据源来自外部，务必用try-with-resources包住。

6. 性能快照：Stream到底比for循环慢还是快

6.1 时间复杂度与内存开销的真实数据

业界对"Stream比for慢"的争论由来已久。我用JMH做过一组粗测（数据源是10万元素的字符串数组，机器是普通开发机），结论供参考：直接for循环+Integer.valueOf大约耗时12ms左右；map+collect大约15ms；mapToInt+boxed+collect大约14ms。差距在20%以内，对于绝大多数业务接口来说完全可以忽略。

真正需要警惕的不是Stream的基本转换性能，而是两种隐性开销。第一种是装箱内存开销：10万个String转成10万个Integer对象，每个Integer对象在堆上占16字节左右（还有可能触发GC），如果你的服务接口QPS很高、每次请求都这么转换，GC压力会累积。第二种是Collectors.toList()内部的ArrayList扩容：如果源数据量大且长度不确定，ArrayList会反复扩容拷贝。如果能提前知道数组大小，可以这样优化：

List<Integer> list = Arrays.stream(arr) .map(Integer::valueOf) .collect(Collectors.toCollection(() -> new ArrayList<>(arr.length)));

用toCollection指定初始容量，避免扩容开销。数组越大，这个优化收益越明显。

6.2 parallelStream到底该不该用

并行流的诱惑力很大，但99%的场景我不建议在字符串转整数时用parallelStream。原因在于：字符串解析和整数装箱都是CPU密集型小任务，并行拆分、任务调度、线程合并的开销往往抵消掉并行收益。10万元素根本不够看，百万级别或许有微弱优势，但百万级转换本身也就百毫秒，没必要冒险。

更重要的是并行流的线程安全问题：如果你在lambda里访问了共享可变状态（比如往外部List里add），并行流会直接打出并发修改异常或者静默产生脏数据。即便代码看起来没问题，线程切换和内存屏障也会让你的性能优势荡然无存。

我自己使用并行流的唯一场景是：数据量在千万级、每个元素的处理逻辑涉及IO或复杂计算，并且处理逻辑是纯函数（无副作用）。"字符串数组转List<Integer>"这种纯CPU转换，老老实实用串行流就够了。

6.3 一个性能优化案例：把filter和map的顺序调一调

Stream中操作顺序直接影响性能。看这两种写法：

// 写法A：先filter后map Arrays.stream(arr) .filter(s -> s != null && !s.trim().isEmpty()) .map(Integer::valueOf) .collect(Collectors.toList()); // 写法B：先map后filter Arrays.stream(arr) .map(Integer::valueOf) // 此处会对脏数据抛异常 .filter(Objects::nonNull) .collect(Collectors.toList());

写法B在map阶段就可能抛异常，根本走不到filter。所以在这种场景下，filter必须在map之前，这是正确性要求，不只是性能问题。

再举一个性能和正确性权衡的例子：

// 先distinct再map vs 先map再distinct Arrays.stream(arr) .filter(Objects::nonNull) .distinct() .map(Integer::valueOf) .collect(Collectors.toList());

这里先对字符串做distinct再map，能减少map的执行次数，性能更好。但要注意字符串去重和整数去重的语义不完全一致："01"和"1"在字符串层面是两个元素，转成Integer后都是1，所以先按字符串去重并不会得到"整数唯一"的结果。如果业务要求整数唯一，必须先map再distinct。这是典型的"性能优化不能牺牲语义"的例子。

7. 实际项目中的连环坑：Stream生命周期与第三方库交互

7.1 数组转List的几个经典陷阱

字符串数组转List<Integer>只是整个链路的一环，实际项目里数组转List的其他姿势同样到处都是坑。

Arrays.asList(arr)返回的是固定大小的List，底层还是那个数组，对它做add或remove会抛UnsupportedOperationException。如果你后续代码要往List里加元素，得包一层new ArrayList<>(Arrays.asList(arr))。

Collections.addAll(list, arr)是另一种常见手法，它把数组元素逐个添加到目标集合，没有定长问题。但它要求目标集合已经存在，不像Stream可以一步到位创建新集合。

List.of(arr)（Java 9+）返回的是不可变List，连set都禁止，null元素也禁止。如果你接手的是Java 9以上的项目，看到List.of要立刻意识到不可变性。很多人把List.of(arr)的结果传到下游方法里尝试add，直接抛异常，还以为是业务bug。

回到正题，如果你已经有Stream<String>，除了map+collect之外，还有一个小众写法：

List<Integer> list = Arrays.stream(arr) .map(Integer::valueOf) .collect(Collectors.collectingAndThen(Collectors.toList(), Collections::unmodifiableList));

collectingAndThen可以在收集完成后立刻包装成不可变List。如果你的下游代码要对外暴露这个List，建议用这种写法，避免调用方意外修改集合导致脏数据。

7.2 Stream流不能重用的底层原理与规避方式

前面说过Stream不能二次消费，这里补充一个场景：方法里先构建Stream，调用anyMatch判断是否存在合法数字，再用同一个Stream统计数量。此时第二个操作必然抛异常。原因在于Stream的内部状态机：一旦终端操作触发，sourceStage就被标记为已消费，后续任何操作都会触发IllegalStateException。

解决方案其实简单：中间结果落List：

List<Integer> numbers = Arrays.stream(arr) .filter(this::isValidNumber) .map(Integer::valueOf) .collect(Collectors.toList()); boolean hasValid = !numbers.isEmpty(); long count = numbers.size();

这样每个业务判断都基于List重新开始，既清晰又安全。我见过一些同事试图保存Stream引用并通过复用绕开限制，实际上Stream根本没有提供任何重置或克隆机制，不要浪费时间在这上面。

7.3 与MongoDB嵌套List、Redis List交互时的注意点

实际项目里，"字符串数组转List<Integer>"往往只是数据准备的起点。以MongoDB为例，查询条件经常要求List<Integer>作为字段值，如果你把转换好的List<Integer>直接塞给Spring Data MongoDB的Query，大部分场景没问题。但当你需要查询"list字段的嵌套list"时，转换逻辑要格外小心：

// 假设文档结构：{"tags": [1, 2, [3, 4]]} // Mongo在比较嵌套数字时，字符串和数字不会自动匹配，必须在Java侧先转Integer List<Object> nestedValues = Arrays.stream(arr) .map(Integer::valueOf) .collect(Collectors.toList());

如果忽略类型匹配，MongoDB会查出完全不同的结果——字符串"1"和整数1在BSON里是两个不同的值。这种问题排查起来非常隐蔽，因为从浏览器工具看数据"差不多"。

Redis的List存储的是字节数组，和JVM的List<Integer>是两套体系。如果你用RedisTemplate存的是List<Integer>，序列化方案默认用JDK序列化，存进去的是一坨二进制，其他语言根本读不了。建议在转换后配合JSON序列化再写入Redis：

List<Integer> ids = Arrays.stream(arr).map(Integer::valueOf).collect(Collectors.toList()); stringRedisTemplate.opsForValue().set("user:ids", objectMapper.writeValueAsString(ids));

这些都属于"转换只是第一步"的延伸场景，但恰恰是这些延伸场景里的类型边界，才是线上事故的高发区。

8. 场景扩展：从字符串数组到更复杂的Stream处理

8.1 多字段排序、过滤去重与分组的一次性解决

当数据从"数组转List"升级为"List<Integer>还要做排序、去重、分组"时，Stream的价值会更明显。

String[] raw = {"5", "3", "3", "1", "2", "4"}; List<Integer> sorted = Arrays.stream(raw) .map(Integer::valueOf) .sorted() .collect(Collectors.toList()); List<Integer> descSorted = Arrays.stream(raw) .map(Integer::valueOf) .sorted(Comparator.reverseOrder()) .collect(Collectors.toList());

如果用循环写排序，你得先转成List再调用Collections.sort，还要自己写Comparator。Stream的sorted()直接内联在链路里，阅读代码时整个操作链一目了然。

对于更复杂的场景，比如按整数的奇偶性分组：

Map<Boolean, List<Integer>> partitioned = Arrays.stream(raw) .map(Integer::valueOf) .collect(Collectors.partitioningBy(n -> n % 2 == 0));

partitioningBy返回的Map泛型是Map<Boolean, List<Integer>>，key为true的是偶数集合，false是奇数集合。这一步在传统的命令式写法里需要先建两个List再遍历填充，代码量和出错概率都比Stream高不少。

8.2 Stream多字段排序：从List<Integer>到对象List的组合用法

如果你的数据不是简单的整数数组，而是一个由字符串数组转换而来的对象集合，多字段排序的需求就出现了。假设你有一个User对象，包含id和age字段，你从文件读了一堆"id,age"格式的字符串：

String[] lines = {"3,25", "1,30", "2,22", "1,18"}; List<User> users = Arrays.stream(lines) .map(line -> line.split(",")) .filter(parts -> parts.length == 2) .map(parts -> new User(Integer.valueOf(parts[0]), Integer.valueOf(parts[1]))) .sorted(Comparator.comparing(User::getId) .thenComparing(User::getAge)) .collect(Collectors.toList());

Comparator.comparing配合thenComparing可以实现多级排序，并且在比较时自动拆箱比较int，不需要你显式写比较逻辑。如果要用循环实现同样的逻辑，至少要额外写一个十几行的Comparator匿名类。Stream链式写法把"解析-过滤-转换-排序-收集"整个流水线凝聚为一段可读性极强的代码，这就是它在实际项目中不可替代的原因。

有一种场景值得特别注意：Comparator.comparing在比较Integer时不会自动处理null，如果你过滤阶段保留下来的元素可能有null，需要在Comparator里加Comparator.nullsLast(...)，否则排序时遇到null会抛NullPointerException。这类细节不踩一次坑很难记住。

9. 完整案例：从CSV文件读取字符串数组并转换为List<Integer>

9.1 案例背景与需求拆解

假设你要做一个批处理任务：从一个CSV文件读取一列用户ID，文件内容长这样：

user_id 1001 1002 1003 1004,1005 2001

业务要求：忽略空行，忽略注释行（以#开头），把逗号分隔的多个ID也拆开，最终得到一个去重后的List<Integer>，并按升序排序后入库。

这个需求在真实项目中太常见了，但它一次涵盖了文件读取、空行过滤、逗号拆分、类型转换、去重、排序六个动作。用传统命令式写，没有30行拿不下来。用Stream链式写，代码非常干净：

Path path = Paths.get("user_ids.csv"); List<Integer> userIds; try (Stream<String> lines = Files.lines(path)) { userIds = lines .map(String::trim) .filter(line -> !line.isEmpty()) .filter(line -> !line.startsWith("#")) .filter(line -> !"user_id".equalsIgnoreCase(line)) .flatMap(line -> Arrays.stream(line.split(","))) .map(String::trim) .filter(s -> !s.isEmpty()) .map(Integer::valueOf) .distinct() .sorted() .collect(Collectors.toList()); } catch (IOException e) { throw new IllegalStateException("读取用户ID文件失败", e); }

这段代码有几个关键点值得展开。

Files.lines(path)返回Stream<String>，并且是一个需要关闭的I/O流，所以必须用try-with-resources包住。很多人在这里漏掉关闭，程序跑一段时间就会报"Too many open files"，而且这个报错经常出现在完全不相干的地方，排查起来极其痛苦。

flatMap(line -> Arrays.stream(line.split(",")))负责把"1004,1005"这种一行多值的情况拆开。flatMap的语义是"把每个元素映射成一个Stream，然后把所有Stream合并成一个"，它是处理一对多映射的标准工具。如果用map来拆分，得到的是Stream<String[]>，还需要再嵌套一次遍历才能拿到单个字符串，代码会难看很多。

distinct()和sorted()的位置都放在map(Integer::valueOf)之后，保证去重和排序都是基于整数值进行的，如前所述，这是语义正确性要求。

9.2 与StarRocks/ClickHouse类工具配合时的类型注意

这类批处理任务经常要把最终的List<Integer>写入OLAP引擎（StarRocks、ClickHouse等），或者作为查询参数传递。由于这类引擎对整数类型检查非常严格，List<Integer>中如果混入null（来自Integer.valueOf无法处理的字符串被你放过来了），很容易在写入或查询阶段触发异常。

我习惯在收集前加一道filter(Objects::nonNull)：

.map(this::tryParse) .filter(Objects::nonNull)

即使tryParse已经排除了大部分脏数据，保险起见再加一道过滤成本极低，但能省掉下游一堆排查时间。另外需要提醒的是，如果最后要写入数据库，List<Integer>里有重复值会影响主键或唯一索引约束，distinct()这一步不能省。

10. 排查实录：几个真实踩坑案例

10.1 案例一：Stream被重复消费导致接口报错

有一次我在负责一个报表接口，代码已经上线跑了很久。某天同事加了一个小功能：读取配置项里的商品ID字符串数组，先判断是否存在某个商品，再统计数量。他的实现是这样的：

Stream<Integer> stream = Arrays.stream(configIds) .map(Integer::valueOf); boolean exists = stream.anyMatch(id -> id.equals(specialId)); long count = stream.count(); // 这里抛异常

问题就在于stream被消费了两次。第一次调用anyMatch时，Stream的内部状态已经变成"已消费"，第二次count()直接抛IllegalStateException。这不是偶发问题，而是每次请求都会稳定复现的。排查时我们花了很多时间看日志，因为IllegalStateException的错误提示对这个场景来说有点抽象，最终在代码评审环节发现是两个方法共用了一个Stream对象引用。

解决方式很简单：把第一次判断的结果存成boolean，然后基于configIds重新构建Stream做count。我后来总结了一个经验：任何需要复用数据源两次及以上的场景，第一时间把Stream落成List，不要让Stream引用在方法之间传递。

10.2 案例二：空字符串混入导致整批数据解析失败

另一个印象深刻的案例是，从一个第三方接口返回的JSON里抽出一个字符串数组，直接传给Integer::valueOf做转换，结果返回值里混了一个空字符串，整个批次转换抛出NumberFormatException: For input string: ""，导致接口直接返回500。

排查过程也很典型：先看接口返回的原始JSON，发现数组里确实有一个空字符串。数据源头是上游系统的一个可空字段，序列化时给出了空串而不是null。我们最初以为是上游bug，后来发现这种情况在合作系统里很常见，正确的做法是自己的服务做好健壮性兜底，不能指望所有上游都规范。

最后我们把转换入口统一封装成工具方法：

public static List<Integer> parseIntList(String[] arr) { if (arr == null) { return Collections.emptyList(); } return Arrays.stream(arr) .filter(Objects::nonNull) .map(String::trim) .filter(s -> !s.isEmpty()) .map(s -> { try { return Integer.valueOf(s); } catch (NumberFormatException e) { return null; } }) .filter(Objects::nonNull) .collect(Collectors.toList()); }

这个工具方法后来被多个项目复用，基本杜绝了同类问题。在这里我可以坦白说一句：实际项目里这些边界处理代码看起来啰嗦，但它们才是真正经受过线上检验的部分，每一行都有对应的血泪史。

10.3 案例三：ArrayList扩容导致的Full GC

这个案例有点进阶。某个批处理服务需要把数百万条字符串ID转成List<Integer>，然后分批写入下游系统。最初实现直接用collect(Collectors.toList())，高峰期出现了比较频繁的Young GC和偶发Full GC。排查时发现Collectors.toList()内部使用的ArrayList默认从空数组开始，逐次扩容，大数量下会有多次数组复制，老年代里积累了大量生命周期极短的数组对象。

优化方案是把收集目标改为预分配容量：

List<Integer> ids = Arrays.stream(arr) .map(Integer::valueOf) .collect(Collectors.toCollection(() -> new ArrayList<>(arr.length)));

因为数组长度已知，一次分配到位，避免扩容。这个改动把Full GC频率明显降了下来。对大多数业务来说这个优化不一定有感知，但如果你在维护一个高吞吐的批处理应用，这类细节值得留意。

11. 快问快答：常见问题速查表

结合搜索引擎里大家最常搜的热门问题，我整理了一张速查表，按高频程度排列。

这张表里的每一条都来自搜索引擎的常见检索词，基本上也是我这些年被问得最多的问题。排查这类问题有一个通用的思路：先看数据内容是否干净，再看Stream生命周期是否正确，最后检查集合的可变性与线程安全。按这个顺序走，大部分问题都能在十分钟内定位。

最后分享一个我个人的习惯：凡是写"字符串转整数"的工具方法，我统一命名为parseIntList，并且放到基础设施工具类里，不允许在业务代码里到处都是Arrays.stream(arr).map(Integer::valueOf)这样的裸写代码。统一的封装让异常处理策略、判空逻辑、空值策略保持一致，也方便日后统一优化。团队协作时，这种"看起来冗余"的统一入口，节省的是大量重复排障的时间。