第 25 天终于轮到 Lambda 表达式了。这个时间点很有意思项目推进到这个阶段我们已经有了不少真实的业务代码可以做对比而不是像刚学 Java 时那样对着语法演示空想。Lambda 这个词在 Java 圈里被提了好几年从 Java 8 正式引入算起如今已经是最基础的能力之一。但我平时看团队里的代码发现很多人只是把 Lambda 当成少写几个字的糖真正理解函数式编程思想、并且能把集合遍历从传统的 for 循环优化到 Stream Lambda 写法的人其实并不多。这篇文章我不想罗列 API而是结合项目里真实存在的遍历场景把 Lambda 的核心原理、函数式编程的入门思路、以及集合遍历优化的实操方法一起讲透。1. 从匿名内部类说起Lambda 到底解决什么问题1.1 写接口实现的老传统在 Java 8 之前我们写一个线程或者写一个比较器都需要一段接口实现样板代码。我拿项目里最常见的场景举例给一个用户列表按年龄排序ListUser users loadUsers(); Collections.sort(users, new ComparatorUser() { Override public int compare(User u1, User u2) { return Integer.compare(u1.getAge(), u2.getAge()); } });这段代码里真正有价值的逻辑其实只有一行return Integer.compare(u1.getAge(), u2.getAge());但为了这一行我们被迫写了 5 行壳代码。当项目里到处是这样的比较器、Runnable、监听器时代码的信噪比会变得很低。读代码的人要在一堆new、Override、public void xxx()里努力找到那一行真正干活的代码。我见过有的老项目里一个DateComparator类被拆到独立文件里结果全项目有几十个这样的一次性类。它们每一个都不复杂但累加起来就是很大的维护负担。Lambda 表达式的出现本质上就是把这个痛点给解决了我们只需要把真正想做的事写出来让编译器去处理那些样板代码。1.2 函数式接口Lambda 的地基这里要引入一个关键概念函数式接口。简单说就是只包含一个抽象方法的接口。Java 的核心库里有很多这样的接口最熟悉的就是Runnable、Comparator、Callable。在 Java 8 之后语言层面用FunctionalInterface注解来标注这类接口这个注解不是必须的但它是一个约束信号如果在这个注解下的接口里定义了第二个抽象方法编译器会直接报错。为什么要强调只有一个抽象方法因为 Lambda 表达式在底层本质上就是这个接口的实例。你想一下如果接口有多个抽象方法你写一个 Lambda 出来编译器根本不知道它在实现哪个方法这就说不通了。比如我们来写一个最简单的自定义函数式接口FunctionalInterface interface StringProcessor { String process(String input); } StringProcessor toUpperCase input - input.trim().toUpperCase(); System.out.println(toUpperCase.process( hello lambda ));这里toUpperCase这个变量的类型是StringProcessor它背后的实例是一个 Lambda 表达式。JVM 编译时实际上会用invokedynamic指令来动态创建这个实现而不是像匿名内部类那样新增一个 Class 文件。这也是 Lambda 在运行时比匿名内部类更有优势的原因之一省去了类的加载和创建开销。1.3 Lambda 语法拆解与简化规则Lambda 的基本语法有两种形式表达式形式(参数) - 表达式语句块形式(参数) - { 方法体 }我整理了一下项目里常用的简化规则记好这几条就够了参数类型可以省略。编译器会根据上下文做类型推断比如ComparatorString里的s1 - s1.length()会自动推断为 String 类型。只有一个参数时圆括号可以省略。比如list.forEach(item - System.out.println(item))。方法体只有一条语句时大括号和分号可以一起省。比如x - x * 2。方法体只有一条 return 语句时return关键字也可以省。(int a, int b) - a b等价于(int a, int b) - { return a b; }。需要特别提醒一点不是所有场景都适合把 Lambda 写得很短。一行 Lambda 超过两行时老老实实改成语句块形式必要的时候加个换行。我以前见过有人写了一个 3 层嵌套的 Lambda一行超过 200 个字符最后 debug 的时候简直是噩梦。代码不是越短越好是越容易看懂越好这一点在后面讲函数式编程思想的时候还会再提。2. 函数式编程入门换一种思考方式2.1 从命令式到声明式说到函数式编程很多人第一反应是Haskell、Scala 那些语言才搞的东西跟 Java 没关系。其实不是这样Java 8 引入 Lambda 之后Java 已经具备了函数式编程的核心表达能力只是很多人还停留在用 Lambda 写 Runnable的水平。函数式编程和最传统的命令式编程最核心的区别在于命令式编程告诉计算机怎么做函数式编程告诉计算机做什么。我拿项目里一个很常见的场景来解释。假设我们有一个订单列表要找出金额大于 100 元的订单取出它们的订单号并且按照金额降序排列。传统写法是这样ListString result new ArrayList(); for (Order order : orders) { if (order.getAmount() 100) { result.add(order.getOrderNo()); } } result.sort(new ComparatorString() { Override public int compare(String o1, String o2) { return o2.compareTo(o1); } });这个写法里你的关注点会被怎么维护循环变量、怎么往 list 里 add、怎么比较字符串这些细节占据。但如果换成一个熟悉函数式编程的人写出来的代码会是这样ListString result orders.stream() .filter(order - order.getAmount() 100) .map(Order::getOrderNo) .sorted(Comparator.reverseOrder()) .collect(Collectors.toList());一眼看过去思路非常直接先过滤再转换再排序最后收集。你不需要关心底层怎么遍历怎么判断索引越界那些事情 Stream 帮你干了。这种描述你想要的最终结果而不是描述每一步怎么做的思路就是声明式编程。写 Java 业务代码的人最容易犯的毛病是惯性停留在命令式思维里看到数据就在想for 循环怎么套看到集合就在想临时变量怎么装。尝试换一种思考方式你会发现代码结构会清晰非常多。2.2 纯函数与不可变数据既然要讲函数式编程有两个基本概念必须搞清楚纯函数和不可变数据。纯函数指的是同样的输入永远得到同样的输出函数内部不产生任何副作用也就是不修改外部状态。这种函数特别好推理也特别好测试。为什么因为你在测试的时候不需要构造一堆前置环境去模拟它可能依赖的外部状态传参进去看返回值就行了。你可能会觉得这不就是普通方法嘛Java 方法不是都可以传参返回嘛。不对。Java 方法很容易有副作用。最常见的副作用是修改传入的参数对象内部的状态或者修改类内部的成员变量。我举一个真实的例子。项目里有一个统计类里面维护了一个会计数成员变量每个订单经过处理时都会count。本来以为这个统计值只在这个类里面使用结果后来新需求要在多个线程里并发处理一批订单这个变量立刻出现数据错乱。最后排查了半天发现就是因为它修改了共享的可变状态。函数式编程建议大家尽量使用不可变数据不修改已有对象的状态而是生成新的对象。比如用Stream处理完集合后生成一个新集合原来那个集合不动它。这个习惯一旦养成了并发环境下的很多坑天然就避开了。2.3 高阶函数与函数组合高阶函数的定义也很简单接收函数作为参数或者把函数作为返回值。Java 8 之前你做不到这种操作因为方法不能被当作参数传递你只能传一个对象。Lambda 出现之后函数本身变成了一等公民。Lambda 在 Java 里的本质虽然是对象但在语法层面你可以把它理解成一段可以传递的代码。Java 核心库里大量的高阶函数应用最典型的例子就是Comparator链式组合users.sort( Comparator.comparing(User::getAge) .thenComparing(User::getName) .thenComparing(User::getSalary) );这种写法在传统命令式时代几乎不可能这么干净地实现。要做多字段级联排序你得写一个很啰嗦的比较器里面一个字段一个字段地判断。有了 Lambda 和高阶函数组合一行一个字段顺序清晰想加字段就再加一行thenComparing。这就是函数式编程的魅力它提供了一种更接近人类思维方式来表达逻辑的方法。3. 集合遍历优化实战重构旧代码3.1 传统遍历的三个痛点讲完思想层面的东西回到今天的主题集合遍历优化。为什么说优化因为传统 for 循环写法在真实项目里确实存在一些比较明显的问题。第一样板代码冗长。for (int i 0; i list.size(); i)这种写法里面那个i list.size()每次都要写多一个少一个都不对完全没有必要让程序员每次手写这么低级的边界判断。而for-each虽然简洁但它的底层逻辑很简单你没法在遍历的同时做过滤之类的操作还得再套 if。第二太容易出边界 bug。我统计过自己维护的项目里凡是出现IndexOutOfBoundsException的地方几乎都是手写for (int i ...)时踩的坑。要么是边界判定写成了i size要么是不小心在循环体里对同一个 list 做了 remove 操作导致索引移位。这些都是非常隐蔽的运行时错误。第三并行能力基本为零。传统 for 循环如果想多线程并发处理你得自己写线程池、拆任务、合并结果这一套做下来代码量翻十倍。而 Stream 的parallelStream()一行就能把单线程变成并行不需要你关心底层细节。3.2 filter / map / collect 核心操作拆解基于这个痛点现在把 Stream Lambda 处理集合的几个核心操作拆开讲一下。注意这几个方法每个都会接收一个函数式接口filter 过滤接收一个PredicateT说白了就是传一个条件进去返回 true 的留下false 的干掉。ListOrder bigOrders orders.stream() .filter(order - order.getAmount() 1000) .collect(Collectors.toList());这里order - order.getAmount() 1000就是PredicateOrder的实例。如果需要多个条件可以用and()、or()组合。map 转换接收一个FunctionT, R把一种类型转成另一种类型。项目里最典型的就是从实体类提取某个字段。ListString orderNos orders.stream() .map(Order::getOrderNo) .collect(Collectors.toList());collect 收集这是整个 Stream 的终点它做的事情是把处理完的 Stream 转回到集合、Map、或者聚合值。刚才的两个例子都用到了collect(Collectors.toList())这就是收集器的用法。单独拆这几个方法可能显得简单真正厉害的是它们可以串联起来形成一条流水线。我给你一个综合性的例子// 找出金额大于 1000 的订单把订单号转成大写去掉重复按字母排序收集为 List ListString result orders.stream() .filter(order - order.getAmount() 1000) .map(order - order.getOrderNo().toUpperCase()) .distinct() .sorted() .collect(Collectors.toList());你自己感受一下如果用 for 循环写需要多少个临时变量和多少个 if 判断。Stream 流水线写法一旦熟练读代码的速度会快很多。3.3 聚合与分组的 Lambda 写法除了上面的三个基础操作实际项目里经常要处理聚合和分组。以前我们想统计一个部门所有员工的工资总和得写个循环然后一个个累加double total 0; for (Employee e : employees) { if (e.getDepartment().equals(技术部)) { total e.getSalary(); } }用reduce或者sum方法一行搞定double total employees.stream() .filter(e - 技术部.equals(e.getDepartment())) .mapToDouble(Employee::getSalary) .sum();mapToDouble会把 Stream 转成DoubleStream里面自带sum()、average()这些聚合方法。这里要注意mapToDouble的返回类型如果你用的是map()那返回的是StreamDouble后面就没有sum()方法了。再比如按部门分组统计平均工资用groupingByMapString, Double avgSalaryByDept employees.stream() .collect(Collectors.groupingBy( Employee::getDepartment, Collectors.averagingDouble(Employee::getSalary) ));这种写法我相信如果你是第一次看到可能觉得这是什么鬼。但只要你用过一次就再也回不去了。它表达的意思非常精确按部门分组然后对每个组计算平均工资。运行结果是一个MapString, Double键是部门名值是平均工资。3.4 性能不是银弹把性能单列一节是因为这一节最容易误导人。网上很多文章吹 Stream 性能碾压 for 循环我自己实际测过分情况。小集合几百上千条Stream 和 for 循环的性能差异几乎可以忽略你感知不到。大集合几百万条以上串行 Stream 可能比传统 for 循环慢 20%-40%因为 Stream 有额外的拆装箱和中间对象开销。并行流parallel在数据量大、每个元素的处理本身有成本比如 IO、复杂计算的情况下并行流可能快很多倍但如果只是数数、累加这种简单操作并行流的分割合并开销反而会拖慢速度。所以在实际项目中我自己的判断标准是两万条以内直接用 Stream别想性能问题代码可读性更重要几十万条以上做基准测试再说别拍脑袋。下面这个例子是我曾经在一个日志分析脚本里踩过的坑// 有问题的写法parallel 不是万能的 ListString lines Files.readAllLines(path); long count lines.parallelStream() .filter(LogParser::isError) .count();这个场景其实非常适合并行流因为它处理的是文件读取后的字符串过滤没有共享可变状态。但如果把过滤改成往共享 list 里 add那就翻车了。并行流使用的前提条件操作必须是纯函数不能共享可变状态否则数据直接乱掉。4. 方法引用与变量捕获写出更优雅的代码4.1 方法引用的四种形式Lambda 用得多了你会发现有些表达式只是一行简单的方法调用比如order - order.getOrderNo()。这种时候Java 提供了一种更简洁的表达方法引用。方法引用一共有四种形式我平时遇到最多的两种是静态方法引用和实例方法引用。这四种形式是类名::静态方法比如Integer::parseInt对象::实例方法比如System.out::println类名::实例方法比如String::toUpperCase这里需要注意第一个参数会成为调用者实例。构造器引用比如ArrayList::new举个例子你就能感受到方法引用的魅力// 传统 Lambda list.forEach(item - System.out.println(item)); // 方法引用 list.forEach(System.out::println); // 传统 Lambda ListString names users.stream() .map(user - user.getName()) .collect(Collectors.toList()); // 方法引用 ListString names users.stream() .map(User::getName) .collect(Collectors.toList());方法引用确实更省字但有个坑也是团队成员经常问我的类名::实例方法 这个东西为什么第一个参数是调用者实例比如String::toUpperCase它是把传进来的那个字符串作为this调用toUpperCase方法所以它等价于str - str.toUpperCase()。如果你需要的是参数作为 toUpperCase 的参数这种语义那就不是这个形式了。说到底方法引用就是一种语法糖它没有改变任何调用语义只是让代码更声明式了一点。如果你一时想不清楚某个方法引用怎么对应就退回去写 Lambda不丢人。4.2 effectively final 与变量捕获这一节必须讲因为我在项目里见过太多人在这里报错后一脸懵。Lambda 表达式可以访问外部局部变量但这个变量必须是final 或 effectively final。什么是 effectively final就是这个变量初始化之后再也没有被重新赋值过。下面这段代码IDE 会直接标红int base 10; base; // 编译错误base 不是 effectively final FunctionInteger, Integer f x - x base;为什么 Lambda 捕获外部变量要求必须有效不可变这牵扯到字节码层面Lambda 表达式捕获的变量实际上是在创建 Lambda 的函数式接口实例时被拷贝了一份快照放进对象里的。如果允许外部变量后续修改你无法保证 Lambda 实例里的快照和外部变量保持同步会导致很隐晦的并发问题。为了防止这种问题Java 语言设计者直接规定捕获的变量必须不可再赋值。我遇到过一个真实案例有同事在一个循环里用 Lambda 创建了一组任务循环变量是int i然后他在 Lambda 里直接使用i编译不过。然后把i换成了final的副本final int index i就没问题了。这个改动背后就是 effectively final 的机制。4.3 常见错误排查手册我把平时遇到的 Lambda 使用问题整理成一张速查表方便你排查症状原因解决方案编译报错 not effectively finalLambda 捕获了后续被重新赋值的变量用一个 final 副本编译报错 target type unknownLambda 没有上下文推断类型也就是不知道是哪个接口类型明确写成SupplierString s () - xxx;方法引用编译错误混淆了类名::实例方法和对象::实例方法退回到 Lambda 写法验证语义forEach 里想 break/continue编译器直接报错或者无法跳出循环改用anyMatch、allMatch或takeWhileJava 9并行流数据错乱使用共享可变集合收集结果改用collect()保证线程安全自动装箱性能差对int/long/double使用了map()而不是mapToInt()等使用基本类型专用 Stream其中最常见的其实是forEach 中想 break。这个没法优雅解决我的建议是换思路如果是要找到第一个满足条件的元素用filter().findFirst()如果是要判断是否存在用anyMatch()。这些都是 Lambda 时代的跳出循环方案。5. 实操经验与避坑心得5.1 团队落地 Lambda 的规范Lambda 虽好但也不是无脑使用。我在团队里推了近一年的 Lambda Stream最后沉淀下来几条内部规范这里分享给你Lambda 表达式建议不超过 3 行。超过 3 行就抽成独立方法用方法引用调用。禁止在 Lambda 里修改外部集合的变量。要修改用map生成新值而不是在循环里set。避免多层嵌套 Lambda。嵌套一层已经要看一会儿了三层直接重构。优先使用核心库提供的函数式接口比如Predicate、Function、Consumer不要随便自定义函数式接口。举个例子我们项目里有个转化率统计的代码原来是一个 80 行的 for 循环嵌套 if-else一个维护它的同事看了半天都不敢改。后来我们改成 Stream 流水线80 行变 20 行。但注意这 20 行不是一下子就写出来的而是先把每个 if-else 分支抽成有名字的方法再用 Lambda 把这些方法像积木一样拼起来。可读性的关键是方法名看得懂Lambda 只负责组合不负责复杂逻辑。5.2 并行流与装箱陷阱如果说这一章只能记住两个避坑点那就是并行流要小心共享状态基本类型遍历要用mapToInt而不是map。自动装箱的坑很隐蔽。你写list.stream().map(x - x 1)的时候x是Integer对象x 1先拆箱、再加、再装箱。如果集合有几百万条这个拆箱装箱的开销就显现出来了。解决办法是用专用流// 性能更好的写法 int sum list.stream() .mapToInt(Integer::intValue) .sum();并行流的坑前面提到过再补一个 5.1 节讲过的场景不要用parallelStream()去处理那种共享可写集合的收集操作。下面这种写法就是经典的错误ListItem items new ArrayList(); list.parallelStream() .filter(item - item.isValid()) .forEach(item - items.add(item)); // 线程不安全正确做法是ListItem items list.parallelStream() .filter(Item::isValid) .collect(Collectors.toList());一字之差结果天壤之别。第一种写法在数据量小的运气下可能看不出来问题数据量一大并发ArrayList.add就会导致元素丢失甚至数组越界。5.3 最后的个人心得Day 25 这个节点回看我从一开始觉得 Lambda 只是语法糖到后来真正从函数式思维去思考问题最大的转变是写代码的时候我更倾向于描述我要什么而不是怎么一步步做。这种思维模式在集合处理、事件回调、并发编程这些场景里确实能降低代码的心智负担。如果你还没用过 Lambda 处理集合我建议你找一段自己过去写的烂代码不要多几十行就行专门挑那种 for 循环里嵌套 if 的试着用 Stream 流水线重写一遍。写完后对比一下你会立刻感受到区别。最后分享一个调试技巧Stream 流水线在中间环节出了问题不好排查你可以用peek方法在中间打印一下数据流。比如ListString result orders.stream() .peek(o - System.out.println(before filter: o.getOrderNo())) .filter(o - o.getAmount() 100) .peek(o - System.out.println(after filter: o.getOrderNo())) .map(Order::getOrderNo) .collect(Collectors.toList());peek的存在就是为了调试它跟forEach很像但它是中间的延迟方法不影响最终结果。不过它有一个性能陷阱生产代码里不建议留太多peek调试完记得删掉。这就是纯粹的调试工具别把业务逻辑写在里面。Lambda 表达式这个东西上手只需要半小时但真正熟练到能随时切换函数式思维我觉得至少需要两三个项目的实际使用。Day 25 是这趟旅程的一个里程碑剩下的路还是要靠你在真实代码里一点点磨。
第 25 天终于轮到 Lambda 表达式了。这个时间点很有意思项目推进到这个阶段我们已经有了不少真实的业务代码可以做对比而不是像刚学 Java 时那样对着语法演示空想。Lambda 这个词在 Java 圈里被提了好几年从 Java 8 正式引入算起如今已经是最基础的能力之一。但我平时看团队里的代码发现很多人只是把 Lambda 当成少写几个字的糖真正理解函数式编程思想、并且能把集合遍历从传统的 for 循环优化到 Stream Lambda 写法的人其实并不多。这篇文章我不想罗列 API而是结合项目里真实存在的遍历场景把 Lambda 的核心原理、函数式编程的入门思路、以及集合遍历优化的实操方法一起讲透。1. 从匿名内部类说起Lambda 到底解决什么问题1.1 写接口实现的老传统在 Java 8 之前我们写一个线程或者写一个比较器都需要一段接口实现样板代码。我拿项目里最常见的场景举例给一个用户列表按年龄排序ListUser users loadUsers(); Collections.sort(users, new ComparatorUser() { Override public int compare(User u1, User u2) { return Integer.compare(u1.getAge(), u2.getAge()); } });这段代码里真正有价值的逻辑其实只有一行return Integer.compare(u1.getAge(), u2.getAge());但为了这一行我们被迫写了 5 行壳代码。当项目里到处是这样的比较器、Runnable、监听器时代码的信噪比会变得很低。读代码的人要在一堆new、Override、public void xxx()里努力找到那一行真正干活的代码。我见过有的老项目里一个DateComparator类被拆到独立文件里结果全项目有几十个这样的一次性类。它们每一个都不复杂但累加起来就是很大的维护负担。Lambda 表达式的出现本质上就是把这个痛点给解决了我们只需要把真正想做的事写出来让编译器去处理那些样板代码。1.2 函数式接口Lambda 的地基这里要引入一个关键概念函数式接口。简单说就是只包含一个抽象方法的接口。Java 的核心库里有很多这样的接口最熟悉的就是Runnable、Comparator、Callable。在 Java 8 之后语言层面用FunctionalInterface注解来标注这类接口这个注解不是必须的但它是一个约束信号如果在这个注解下的接口里定义了第二个抽象方法编译器会直接报错。为什么要强调只有一个抽象方法因为 Lambda 表达式在底层本质上就是这个接口的实例。你想一下如果接口有多个抽象方法你写一个 Lambda 出来编译器根本不知道它在实现哪个方法这就说不通了。比如我们来写一个最简单的自定义函数式接口FunctionalInterface interface StringProcessor { String process(String input); } StringProcessor toUpperCase input - input.trim().toUpperCase(); System.out.println(toUpperCase.process( hello lambda ));这里toUpperCase这个变量的类型是StringProcessor它背后的实例是一个 Lambda 表达式。JVM 编译时实际上会用invokedynamic指令来动态创建这个实现而不是像匿名内部类那样新增一个 Class 文件。这也是 Lambda 在运行时比匿名内部类更有优势的原因之一省去了类的加载和创建开销。1.3 Lambda 语法拆解与简化规则Lambda 的基本语法有两种形式表达式形式(参数) - 表达式语句块形式(参数) - { 方法体 }我整理了一下项目里常用的简化规则记好这几条就够了参数类型可以省略。编译器会根据上下文做类型推断比如ComparatorString里的s1 - s1.length()会自动推断为 String 类型。只有一个参数时圆括号可以省略。比如list.forEach(item - System.out.println(item))。方法体只有一条语句时大括号和分号可以一起省。比如x - x * 2。方法体只有一条 return 语句时return关键字也可以省。(int a, int b) - a b等价于(int a, int b) - { return a b; }。需要特别提醒一点不是所有场景都适合把 Lambda 写得很短。一行 Lambda 超过两行时老老实实改成语句块形式必要的时候加个换行。我以前见过有人写了一个 3 层嵌套的 Lambda一行超过 200 个字符最后 debug 的时候简直是噩梦。代码不是越短越好是越容易看懂越好这一点在后面讲函数式编程思想的时候还会再提。2. 函数式编程入门换一种思考方式2.1 从命令式到声明式说到函数式编程很多人第一反应是Haskell、Scala 那些语言才搞的东西跟 Java 没关系。其实不是这样Java 8 引入 Lambda 之后Java 已经具备了函数式编程的核心表达能力只是很多人还停留在用 Lambda 写 Runnable的水平。函数式编程和最传统的命令式编程最核心的区别在于命令式编程告诉计算机怎么做函数式编程告诉计算机做什么。我拿项目里一个很常见的场景来解释。假设我们有一个订单列表要找出金额大于 100 元的订单取出它们的订单号并且按照金额降序排列。传统写法是这样ListString result new ArrayList(); for (Order order : orders) { if (order.getAmount() 100) { result.add(order.getOrderNo()); } } result.sort(new ComparatorString() { Override public int compare(String o1, String o2) { return o2.compareTo(o1); } });这个写法里你的关注点会被怎么维护循环变量、怎么往 list 里 add、怎么比较字符串这些细节占据。但如果换成一个熟悉函数式编程的人写出来的代码会是这样ListString result orders.stream() .filter(order - order.getAmount() 100) .map(Order::getOrderNo) .sorted(Comparator.reverseOrder()) .collect(Collectors.toList());一眼看过去思路非常直接先过滤再转换再排序最后收集。你不需要关心底层怎么遍历怎么判断索引越界那些事情 Stream 帮你干了。这种描述你想要的最终结果而不是描述每一步怎么做的思路就是声明式编程。写 Java 业务代码的人最容易犯的毛病是惯性停留在命令式思维里看到数据就在想for 循环怎么套看到集合就在想临时变量怎么装。尝试换一种思考方式你会发现代码结构会清晰非常多。2.2 纯函数与不可变数据既然要讲函数式编程有两个基本概念必须搞清楚纯函数和不可变数据。纯函数指的是同样的输入永远得到同样的输出函数内部不产生任何副作用也就是不修改外部状态。这种函数特别好推理也特别好测试。为什么因为你在测试的时候不需要构造一堆前置环境去模拟它可能依赖的外部状态传参进去看返回值就行了。你可能会觉得这不就是普通方法嘛Java 方法不是都可以传参返回嘛。不对。Java 方法很容易有副作用。最常见的副作用是修改传入的参数对象内部的状态或者修改类内部的成员变量。我举一个真实的例子。项目里有一个统计类里面维护了一个会计数成员变量每个订单经过处理时都会count。本来以为这个统计值只在这个类里面使用结果后来新需求要在多个线程里并发处理一批订单这个变量立刻出现数据错乱。最后排查了半天发现就是因为它修改了共享的可变状态。函数式编程建议大家尽量使用不可变数据不修改已有对象的状态而是生成新的对象。比如用Stream处理完集合后生成一个新集合原来那个集合不动它。这个习惯一旦养成了并发环境下的很多坑天然就避开了。2.3 高阶函数与函数组合高阶函数的定义也很简单接收函数作为参数或者把函数作为返回值。Java 8 之前你做不到这种操作因为方法不能被当作参数传递你只能传一个对象。Lambda 出现之后函数本身变成了一等公民。Lambda 在 Java 里的本质虽然是对象但在语法层面你可以把它理解成一段可以传递的代码。Java 核心库里大量的高阶函数应用最典型的例子就是Comparator链式组合users.sort( Comparator.comparing(User::getAge) .thenComparing(User::getName) .thenComparing(User::getSalary) );这种写法在传统命令式时代几乎不可能这么干净地实现。要做多字段级联排序你得写一个很啰嗦的比较器里面一个字段一个字段地判断。有了 Lambda 和高阶函数组合一行一个字段顺序清晰想加字段就再加一行thenComparing。这就是函数式编程的魅力它提供了一种更接近人类思维方式来表达逻辑的方法。3. 集合遍历优化实战重构旧代码3.1 传统遍历的三个痛点讲完思想层面的东西回到今天的主题集合遍历优化。为什么说优化因为传统 for 循环写法在真实项目里确实存在一些比较明显的问题。第一样板代码冗长。for (int i 0; i list.size(); i)这种写法里面那个i list.size()每次都要写多一个少一个都不对完全没有必要让程序员每次手写这么低级的边界判断。而for-each虽然简洁但它的底层逻辑很简单你没法在遍历的同时做过滤之类的操作还得再套 if。第二太容易出边界 bug。我统计过自己维护的项目里凡是出现IndexOutOfBoundsException的地方几乎都是手写for (int i ...)时踩的坑。要么是边界判定写成了i size要么是不小心在循环体里对同一个 list 做了 remove 操作导致索引移位。这些都是非常隐蔽的运行时错误。第三并行能力基本为零。传统 for 循环如果想多线程并发处理你得自己写线程池、拆任务、合并结果这一套做下来代码量翻十倍。而 Stream 的parallelStream()一行就能把单线程变成并行不需要你关心底层细节。3.2 filter / map / collect 核心操作拆解基于这个痛点现在把 Stream Lambda 处理集合的几个核心操作拆开讲一下。注意这几个方法每个都会接收一个函数式接口filter 过滤接收一个PredicateT说白了就是传一个条件进去返回 true 的留下false 的干掉。ListOrder bigOrders orders.stream() .filter(order - order.getAmount() 1000) .collect(Collectors.toList());这里order - order.getAmount() 1000就是PredicateOrder的实例。如果需要多个条件可以用and()、or()组合。map 转换接收一个FunctionT, R把一种类型转成另一种类型。项目里最典型的就是从实体类提取某个字段。ListString orderNos orders.stream() .map(Order::getOrderNo) .collect(Collectors.toList());collect 收集这是整个 Stream 的终点它做的事情是把处理完的 Stream 转回到集合、Map、或者聚合值。刚才的两个例子都用到了collect(Collectors.toList())这就是收集器的用法。单独拆这几个方法可能显得简单真正厉害的是它们可以串联起来形成一条流水线。我给你一个综合性的例子// 找出金额大于 1000 的订单把订单号转成大写去掉重复按字母排序收集为 List ListString result orders.stream() .filter(order - order.getAmount() 1000) .map(order - order.getOrderNo().toUpperCase()) .distinct() .sorted() .collect(Collectors.toList());你自己感受一下如果用 for 循环写需要多少个临时变量和多少个 if 判断。Stream 流水线写法一旦熟练读代码的速度会快很多。3.3 聚合与分组的 Lambda 写法除了上面的三个基础操作实际项目里经常要处理聚合和分组。以前我们想统计一个部门所有员工的工资总和得写个循环然后一个个累加double total 0; for (Employee e : employees) { if (e.getDepartment().equals(技术部)) { total e.getSalary(); } }用reduce或者sum方法一行搞定double total employees.stream() .filter(e - 技术部.equals(e.getDepartment())) .mapToDouble(Employee::getSalary) .sum();mapToDouble会把 Stream 转成DoubleStream里面自带sum()、average()这些聚合方法。这里要注意mapToDouble的返回类型如果你用的是map()那返回的是StreamDouble后面就没有sum()方法了。再比如按部门分组统计平均工资用groupingByMapString, Double avgSalaryByDept employees.stream() .collect(Collectors.groupingBy( Employee::getDepartment, Collectors.averagingDouble(Employee::getSalary) ));这种写法我相信如果你是第一次看到可能觉得这是什么鬼。但只要你用过一次就再也回不去了。它表达的意思非常精确按部门分组然后对每个组计算平均工资。运行结果是一个MapString, Double键是部门名值是平均工资。3.4 性能不是银弹把性能单列一节是因为这一节最容易误导人。网上很多文章吹 Stream 性能碾压 for 循环我自己实际测过分情况。小集合几百上千条Stream 和 for 循环的性能差异几乎可以忽略你感知不到。大集合几百万条以上串行 Stream 可能比传统 for 循环慢 20%-40%因为 Stream 有额外的拆装箱和中间对象开销。并行流parallel在数据量大、每个元素的处理本身有成本比如 IO、复杂计算的情况下并行流可能快很多倍但如果只是数数、累加这种简单操作并行流的分割合并开销反而会拖慢速度。所以在实际项目中我自己的判断标准是两万条以内直接用 Stream别想性能问题代码可读性更重要几十万条以上做基准测试再说别拍脑袋。下面这个例子是我曾经在一个日志分析脚本里踩过的坑// 有问题的写法parallel 不是万能的 ListString lines Files.readAllLines(path); long count lines.parallelStream() .filter(LogParser::isError) .count();这个场景其实非常适合并行流因为它处理的是文件读取后的字符串过滤没有共享可变状态。但如果把过滤改成往共享 list 里 add那就翻车了。并行流使用的前提条件操作必须是纯函数不能共享可变状态否则数据直接乱掉。4. 方法引用与变量捕获写出更优雅的代码4.1 方法引用的四种形式Lambda 用得多了你会发现有些表达式只是一行简单的方法调用比如order - order.getOrderNo()。这种时候Java 提供了一种更简洁的表达方法引用。方法引用一共有四种形式我平时遇到最多的两种是静态方法引用和实例方法引用。这四种形式是类名::静态方法比如Integer::parseInt对象::实例方法比如System.out::println类名::实例方法比如String::toUpperCase这里需要注意第一个参数会成为调用者实例。构造器引用比如ArrayList::new举个例子你就能感受到方法引用的魅力// 传统 Lambda list.forEach(item - System.out.println(item)); // 方法引用 list.forEach(System.out::println); // 传统 Lambda ListString names users.stream() .map(user - user.getName()) .collect(Collectors.toList()); // 方法引用 ListString names users.stream() .map(User::getName) .collect(Collectors.toList());方法引用确实更省字但有个坑也是团队成员经常问我的类名::实例方法 这个东西为什么第一个参数是调用者实例比如String::toUpperCase它是把传进来的那个字符串作为this调用toUpperCase方法所以它等价于str - str.toUpperCase()。如果你需要的是参数作为 toUpperCase 的参数这种语义那就不是这个形式了。说到底方法引用就是一种语法糖它没有改变任何调用语义只是让代码更声明式了一点。如果你一时想不清楚某个方法引用怎么对应就退回去写 Lambda不丢人。4.2 effectively final 与变量捕获这一节必须讲因为我在项目里见过太多人在这里报错后一脸懵。Lambda 表达式可以访问外部局部变量但这个变量必须是final 或 effectively final。什么是 effectively final就是这个变量初始化之后再也没有被重新赋值过。下面这段代码IDE 会直接标红int base 10; base; // 编译错误base 不是 effectively final FunctionInteger, Integer f x - x base;为什么 Lambda 捕获外部变量要求必须有效不可变这牵扯到字节码层面Lambda 表达式捕获的变量实际上是在创建 Lambda 的函数式接口实例时被拷贝了一份快照放进对象里的。如果允许外部变量后续修改你无法保证 Lambda 实例里的快照和外部变量保持同步会导致很隐晦的并发问题。为了防止这种问题Java 语言设计者直接规定捕获的变量必须不可再赋值。我遇到过一个真实案例有同事在一个循环里用 Lambda 创建了一组任务循环变量是int i然后他在 Lambda 里直接使用i编译不过。然后把i换成了final的副本final int index i就没问题了。这个改动背后就是 effectively final 的机制。4.3 常见错误排查手册我把平时遇到的 Lambda 使用问题整理成一张速查表方便你排查症状原因解决方案编译报错 not effectively finalLambda 捕获了后续被重新赋值的变量用一个 final 副本编译报错 target type unknownLambda 没有上下文推断类型也就是不知道是哪个接口类型明确写成SupplierString s () - xxx;方法引用编译错误混淆了类名::实例方法和对象::实例方法退回到 Lambda 写法验证语义forEach 里想 break/continue编译器直接报错或者无法跳出循环改用anyMatch、allMatch或takeWhileJava 9并行流数据错乱使用共享可变集合收集结果改用collect()保证线程安全自动装箱性能差对int/long/double使用了map()而不是mapToInt()等使用基本类型专用 Stream其中最常见的其实是forEach 中想 break。这个没法优雅解决我的建议是换思路如果是要找到第一个满足条件的元素用filter().findFirst()如果是要判断是否存在用anyMatch()。这些都是 Lambda 时代的跳出循环方案。5. 实操经验与避坑心得5.1 团队落地 Lambda 的规范Lambda 虽好但也不是无脑使用。我在团队里推了近一年的 Lambda Stream最后沉淀下来几条内部规范这里分享给你Lambda 表达式建议不超过 3 行。超过 3 行就抽成独立方法用方法引用调用。禁止在 Lambda 里修改外部集合的变量。要修改用map生成新值而不是在循环里set。避免多层嵌套 Lambda。嵌套一层已经要看一会儿了三层直接重构。优先使用核心库提供的函数式接口比如Predicate、Function、Consumer不要随便自定义函数式接口。举个例子我们项目里有个转化率统计的代码原来是一个 80 行的 for 循环嵌套 if-else一个维护它的同事看了半天都不敢改。后来我们改成 Stream 流水线80 行变 20 行。但注意这 20 行不是一下子就写出来的而是先把每个 if-else 分支抽成有名字的方法再用 Lambda 把这些方法像积木一样拼起来。可读性的关键是方法名看得懂Lambda 只负责组合不负责复杂逻辑。5.2 并行流与装箱陷阱如果说这一章只能记住两个避坑点那就是并行流要小心共享状态基本类型遍历要用mapToInt而不是map。自动装箱的坑很隐蔽。你写list.stream().map(x - x 1)的时候x是Integer对象x 1先拆箱、再加、再装箱。如果集合有几百万条这个拆箱装箱的开销就显现出来了。解决办法是用专用流// 性能更好的写法 int sum list.stream() .mapToInt(Integer::intValue) .sum();并行流的坑前面提到过再补一个 5.1 节讲过的场景不要用parallelStream()去处理那种共享可写集合的收集操作。下面这种写法就是经典的错误ListItem items new ArrayList(); list.parallelStream() .filter(item - item.isValid()) .forEach(item - items.add(item)); // 线程不安全正确做法是ListItem items list.parallelStream() .filter(Item::isValid) .collect(Collectors.toList());一字之差结果天壤之别。第一种写法在数据量小的运气下可能看不出来问题数据量一大并发ArrayList.add就会导致元素丢失甚至数组越界。5.3 最后的个人心得Day 25 这个节点回看我从一开始觉得 Lambda 只是语法糖到后来真正从函数式思维去思考问题最大的转变是写代码的时候我更倾向于描述我要什么而不是怎么一步步做。这种思维模式在集合处理、事件回调、并发编程这些场景里确实能降低代码的心智负担。如果你还没用过 Lambda 处理集合我建议你找一段自己过去写的烂代码不要多几十行就行专门挑那种 for 循环里嵌套 if 的试着用 Stream 流水线重写一遍。写完后对比一下你会立刻感受到区别。最后分享一个调试技巧Stream 流水线在中间环节出了问题不好排查你可以用peek方法在中间打印一下数据流。比如ListString result orders.stream() .peek(o - System.out.println(before filter: o.getOrderNo())) .filter(o - o.getAmount() 100) .peek(o - System.out.println(after filter: o.getOrderNo())) .map(Order::getOrderNo) .collect(Collectors.toList());peek的存在就是为了调试它跟forEach很像但它是中间的延迟方法不影响最终结果。不过它有一个性能陷阱生产代码里不建议留太多peek调试完记得删掉。这就是纯粹的调试工具别把业务逻辑写在里面。Lambda 表达式这个东西上手只需要半小时但真正熟练到能随时切换函数式思维我觉得至少需要两三个项目的实际使用。Day 25 是这趟旅程的一个里程碑剩下的路还是要靠你在真实代码里一点点磨。
