大厂严禁在Stream高频循环内嵌套创建昂贵对象，因其会迅速填满Eden区、触发毫秒级Young GC，导致STW毛刺、CPU抖动及P99响应突增；昂贵对象指每次new的包装类、集合容器、IO/加解密上下文、正则Pattern等高内存开销且短命的对象。
大厂严禁在 Stream 高频循环内部嵌套组装昂贵对象，核心不是反对 Stream，而是防止隐式高频对象爆炸——每次迭代都新建对象，会迅速填满 Eden 区，触发频繁 Young GC，造成响应毛刺、CPU 抖动甚至服务降级。
昂贵对象指哪些
“昂贵”不单看构造耗时，更看内存开销与生命周期： • 每次 new 的包装类（如 new BigDecimal("123.45")、new SimpleDateFormat("yyyy-MM-dd")） • 每次创建的集合容器（如 Arrays.asList()、new HashMap()、Collectors.toMap() 中的 valueMapper） • 每次初始化的 IO/加解密上下文（如 new Cipher()、new GZIPInputStream()） • 每次构建的正则 Pattern（Pattern.compile() 未复用） 这些对象多数只存活一次 map/filter，却占用数 KB 至 MB 级堆内存，且无法被 JIT 逃逸分析优化掉。
高频循环放大问题指数级
Stream 的中间操作（map/filter）在 forEach 或 collect 触发时才真正执行。一旦输入数据量大（如万级用户列表）、或被放在定时任务/网关路由等高频路径中： • 单次请求可能触发上万次对象分配 • JVM 在几毫秒内就把 Eden 区占满，Young GC 频率从秒级飙升至毫秒级 • GC 线程抢占 CPU，导致业务线程 STW 延迟不可控，APM 显示 P99 响应时间突增 200ms+ • 多个短命对象碎片堆积，加剧晋升压力，间接抬高 Full GC 风险
替代方案要兼顾性能与可读
不是禁止封装，而是把“贵”的动作移出热路径： • 将昂贵对象提取为 static final 字段复用（如 public static final DecimalFormat DF = new DecimalFormat("0.00");） • 把对象组装逻辑拆成独立方法，在 Stream 外预处理或分批缓存（如先 userList.parallelStream().map(User::getId).toList()，再批量查 DB） • 用对象池管理上下文类（如 Apache Commons Pool 管理 Cipher 实例），避免反复初始化/销毁 • 对正则、格式化等工具类，优先使用线程安全的静态方法（如 DateTimeFormatter.ofPattern() 是无状态的，比 new SimpleDateFormat 安全）
编译器和 JIT 并不帮你兜底
Java 编译器不会自动复用 Lambda 内创建的对象；JIT 的逃逸分析在以下场景基本失效： • Lambda 捕获了局部变量（形成闭包，对象必须堆分配） • 对象被传入第三方库方法（如 log.info("user={}", expensiveObj)） • Stream 被并行化（parallelStream()），各线程各自 new，复用更难 所以“写起来顺手”，不等于“跑起来省心”。大厂卡这条红线，是把隐性成本显性化，让性能隐患在编码阶段就暴露出来。
