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。
立即学习“Java免费学习笔记（深入）”；
- 永远假设 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()的流，绝对不要并行——日志输出会串行锁死 - 小集合（ 并行收益
Listdata = 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 的设计哲学藏在它的不可重用性和惰性求值里。很多问题不是语法写错，而是没意识到它本质是一条数据处理流水线，而不是一个容器。
