Java面试——Java 8 Stream流与Lambda表达式_网络技术

Stream.collect() 错误主因是未理解Collector类型推导规则，需明确指定目标类型，优先用toCollection(ArrayList::new)；Lambda参数不可依赖IDE推断；parallelStream()仅适用于纯计算场景；Stream不可重复使用。

Stream.collect() 用法错在没选对 Collector

很多人调用 collect() 时直接传 Collectors.toList()，结果发现返回的是不可变集合或类型不匹配。根本原因是没理解 Collector 的类型推导规则：它由上游元素类型、中间累积容器类型、最终返回类型共同决定。

常见错误现象：ClassCastException（比如想收集为 ArrayList 却拿到 Arrays$ArrayList），或编译报错“no instance(s) of type variable exist”。

要明确指定目标类型，优先用 Collectors.toCollection(ArrayList::new) 而非 toList()
若需去重+排序，别链式写 distinct().sorted().collect(toList())，改用 toCollection(TreeSet::new) 更高效
自定义对象聚合时，Collectors.toMap() 的 key 冲突会抛 IllegalStateException，必须显式提供 merge 函数，如 (v1, v2) -> v1

Lambda 参数类型不能靠 IDE 猜

Java 编译器对 Lambda 的类型推导依赖函数式接口的声明，不是靠上下文“猜”。当方法重载存在、泛型擦除或 Stream 操作链过长时，IDE 显示的参数类型可能是错的，但编译仍可能通过——运行时却出问题。

典型场景：对 Optional 调用 map() 后接 filter()，Lambda 里误写 obj.toString() 却没判空，因为编译器把 map() 返回的 Optional 当成非空，实际 map() 输入为 null 时返回的是空 Optional。

永远假设 Lambda 参数可能为
null，除非上游明确保证（如 Stream.of("a","b")）
避免在 Lambda 中抛受检异常，IOException 这类必须包装成 RuntimeException 或改用专门的工具方法
调试时在 Lambda 里加断点无效？那是 IDE 的限制，改成方法引用（如 String::length）或提前提取为局部变量再传入

parallelStream() 不是性能银弹

并行流默认使用 ForkJoinPool.commonPool()，线程数等于 CPU 核心数减一（JDK 8 默认），一旦有阻塞操作（如数据库查询、文件读写），整个池子会被拖慢，甚至导致其他模块的并行流卡死。

错误认知：“数据量大就上 parallelStream”。真实瓶颈常在 I/O 或同步块，而非 CPU 计算。

只对纯计算型、无状态、无外部依赖的操作启用并行，例如 map(x -> x * x).reduce(0, Integer::sum)
含 synchronized 块或 System.out.println() 的流，绝对不要并行——日志输出会串行锁死
小集合（并行收益

List data = Arrays.asList(1, 2, 3, 4, 5);
// 错：parallelStream + I/O
data.parallelStream().map(x -> {
    try (FileReader r = new FileReader("file" + x + ".txt")) {
        return r.read();
    } catch (IOException e) {
        throw new RuntimeException(e);
    }
}).collect(Collectors.toList());
// 对：拆出 I/O 到主线程，仅对数值计算并行
List results = data.stream()
.map(x -> readFileAsInt("file" + x + ".txt")) // 同步读取
.parallel()
.map(x -> x * x + 10) // 纯计算
.collect(Collectors.toList());

Stream 是一次性消费的，重复使用会抛 IllegalStateException

Stream 设计上就是单次遍历，调用 forEach()、collect()、count() 任一终端操作后，再调用其他终端操作就会触发 java.lang.IllegalStateException: stream has already been operated upon or closed。

这不是 bug，是故意为之——避免隐式状态和并发问题。但面试时有人试图用 stream.reset() 或缓存 Stream 对象，这在标准 API 中不存在。

需要多次消费？要么重新创建 Stream（如 list.stream()），要么先 collect 成集合再反复用
别把 Stream 当作 List 包装器：Stream.generate(Math::random).limit(100) 每次调用都生成新随机数，不能“重放”
调试时打印 Stream 内容？用 peek(System.out::println)，但注意它只是中间操作，必须接终端操作才会执行

Stream 的设计哲学藏在它的不可重用性和惰性求值里。很多问题不是语法写错，而是没意识到它本质是一条数据处理流水线，而不是一个容器。

# java # 工具 # stream # red # String # Integer # NULL # count # foreach # Filter # math # 局部变量 # Lambda # 接口 # Length # 泛型 # 线程 # map # 并发 # 对象 # ide # 数据库 # bug # 的是 # 链式 # 而非 # 里加 # 重复使用 # 是一个 # 就会 # 随机数 # 那是 # 才会

相关栏目：【网站优化151355 】【网络推广146373 】【网络技术251813 】【 AI营销90571 】