Lambda、Stream、record、模式匹配：编译后变成了什么

不懂机制时的典型误用：觉得“Stream 就是更优雅的 for 循环”，在热点路径上对 1000 万个 Long 做 reduce，比 for 循环慢 40 多倍（⑤ 实测）；或者随手 parallelStream()，结果占满了全服务共用的线程池（⑥ 坑 2）。

本页学四样的底层机制。选择规则：值对象一律 record；集合变换用 Stream，热点循环和基本类型大批量运算用 for 或 IntStream / LongStream；封闭的类型族用 sealed + switch，开放的用多态。

④-1invokedynamic：字节码里只写“到时候问引导方法”

④-2Lambda：一个私有静态方法，加一个运行时生成的隐藏类

④-3Stream：先搭流水线，终端操作一来，元素一个一个从头走到尾

• 1中间操作只是在搭链：filter、map、peek 每调一次，只是在后面接一个新的流水线阶段（源码里的 AbstractPipeline），什么都不执行。实测 搭好以后，peek 里一行都没打印。
• 2终端操作才开工：findFirst、toList、reduce 一调用，流水线从尾往头把每个阶段包成一个 Sink（一个 Consumer），串成一条链，然后从数据源一个个推元素进去。
• 3一个元素先走完整条链：66 过 filter 被拦下，88 过 filter、过 map、到 findFirst，拿到了就叫停，99、12、7 根本不碰（短路）。不是“先全部 filter，再全部 map”。
• 4有状态的操作会打断这种流动：sorted、distinct 要看完所有元素才能决定第一个输出，于是在那里“蓄水”，前面的阶段要把全部元素都处理完。实测 加了 sorted 后，5 个元素全被 filter 看过。

订单行按顺序是 66（19.90）、88（299.00）、99（129.00）、12（9.90）、7（599.00），filter 留下单价大于 100 的，sorted 按单价从高到低。模拟和 ⑤ 的 JDK 17 实测输出一致，逻辑在 node 里跑过。

④-4record：编译器生成的类，和它的边界

• 1record OrderLine(long skuId, String name, BigDecimal price, int qty) 编译成一个 final class OrderLine extends java.lang.Record：四个 private final 字段、一个按组件顺序的规范构造器、四个同名访问方法 skuId()……
• 2equals、hashCode、toString 不是写死的字节码，而是一条 indy，引导方法 ObjectMethods.bootstrap 按组件列表生成（④-1）。所以“改了组件，三件套自动跟着变”。
• 3紧凑构造器 OrderLine { if (qty <= 0) throw … }：只写校验和规范化，参数到字段的赋值由编译器补在最后。
• 4class 文件里多了 Record 属性，列出组件名和类型。反射 getRecordComponents() 读的就是它，Jackson 靠它把 JSON 的键对上规范构造器的参数（全景第 2 站）。
• 5只是浅不可变：字段是 final，可字段指向的 List 自己能变。实测 外面往原列表加一行，Cart 里跟着变成 3 行；在紧凑构造器里 List.copyOf 的 SafeCart 还是 2 行。

④-5模式匹配的 switch：按类型分派，再由编译器检查穷举

最少语法

Supplier<String> s = () -> "x";      Function<OrderLine, BigDecimal> f = OrderLine::amount;
BigDecimal sum = lines.stream().map(OrderLine::amount).reduce(BigDecimal.ZERO, BigDecimal::add);
long cnt = LongStream.range(0, n).filter(i -> i % 2 == 0).count();          // 基本类型流，不装箱
Map<Long, List<Order>> byUser = orders.stream().collect(Collectors.groupingBy(Order::userId));
record OrderLine(long skuId, BigDecimal price, int qty) { OrderLine { if (qty <= 0) throw …; } }
if (d instanceof Minus m) { … m.off() … }                                    // JDK 16
return switch (d) { case Minus(var off) -> …; case Percent p -> …; case None n -> sum; };   // JDK 21

• Collector 的四个函数（supplier、accumulator、combiner、finisher），自己写一个 Collector
• Spliterator 和并行拆分：为什么 ArrayList 并行比 LinkedList 好拆
• MethodHandle 和 invokedynamic 的完整机制，以及它和反射的性能差（接 J01“反射、注解与动态代理”）
• 上一圈 JDK 页列过的：结构化并发、AOT 缓存、Valhalla 值类型

自测