Lambda 表达式本身不加速性能，但合理使用可减少冗余开销、提升可维护性并释放 JVM 优化潜力；首次调用有冷启动成本，后续 JIT 编译后性能与普通方法持平甚至更优。
Java 中 Lambda 表达式本身不是性能加速器，但用得合理，能避免冗余开销、提升可维护性，并释放 JVM 的优化潜力。关键不在写法多短，而在选得准、用得稳、避得开。
首次调用有冷启动，后续基本无感
Lambda 第一次执行时，JVM 通过 invokedynamic 指令触发 LambdaMetafactory 动态生成实现类，有微量类加载和实例化成本。但之后复用已生成的实例，JIT 编译后性能与普通方法调用持平，甚至更优（逃逸分析、内联更充分）。高频短任务（如每毫秒新建一个 Lambda）需关注冷启动抖动，JMH 测试务必预热足够轮次（建议 ≥10 轮）。
优先用方法引用，少写冗余 Lambda
当 Lambda 主体只调用一个已有方法且签名匹配时，直接用方法引用更轻量：
- 静态方法：用
Integer::parseInt替代s -> Integer.parseInt(s) - 实例方法：用
list::add替代item -> list.add(item)（注意 list 生命周期） - 构造器：用
ArrayList::new替代() -> new ArrayList()
避免“假方法引用”，比如 s -> s.trim().toLowerCase() 无法简化为单个引用，强行拆分反而增加调用链。
立即学习“Java免费学习笔记（深入）”；
别在循环里反复创建捕获型 Lambda
非捕获 Lambda（如 s -> s.length()）可被 JVM 缓存为单例；捕获外部变量的（如 prefix -> s -> prefix + s）每次都会新建实例，带来分配压力和 GC 开销。
- 高频循环中避免
list.forEach(x -> doSomething(x, config))，若config是局部变量，就属于捕获 - 建议提前声明为
final，或提取为静态常量、成员字段 - 需修改变量时，慎用
AtomicInteger或数组包装——它们引入同步和对象封装开销
并行流不是万能钥匙，看场景再开
parallelStream() 依赖 ForkJoinPool 分片，适合 CPU 密集型、无状态、数据量大的场景（通常 > 10,000 元素）：
- 小数据集、含 I/O 或锁的操作，线程调度和同步开销反而拖慢整体速度
- 简单过滤+映射（
filter().map().collect()）一般无需并行；数值累加、哈希计算等纯计算密集型任务才值得尝试 - 避免
forEach()并行——不保序且不能安全改共享变量；改用forEachOrdered()或先收集再处理
