Lambda 表达式的优缺点

1. Lambda 表达式的优势

Lambda 表达式不仅仅是语法糖，而是让 Java 更接近函数式风格的一步。下面是它们的实际优点，以及为什么在现代代码中用起来如此顺手。

简洁与表达力

在引入 Lambda 之前，简单的“局部”代码常常要写成带有大量模板噪声的匿名类。例如，按长度对字符串排序：

在 Java 8 之前（匿名类）：

list.sort(new Comparator<String>() {
    @Override
    public int compare(String a, String b) {
        return a.length() - b.length();
    }
});

使用 Lambda 表达式：

list.sort((a, b) -> a.length() - b.length());

代码更短，可读性几乎像自然语言：“按长度差排序”。

可读性与对要点的聚焦

Lambda 去除了“样板噪声”——类名、多余的大括号、return 等不增添意义的部分。结果是代码更易读、更易维护：

names.forEach(name -> System.out.println(name));

一目了然：对每个名字——打印它。在这里，了解诸如 forEach 之类的集合方法很有帮助。

将行为作为参数传递

终于可以方便地把“一段行为”作为方法参数传递了。这在集合、Stream API、事件中尤为明显：

示例：过滤数字列表

List<Integer> numbers = Arrays.asList(1, 2, 3, 4, 5);
numbers.removeIf(n -> n % 2 == 0); // 删除偶数

与集合和 Stream API 的良好集成

List<String> words = Arrays.asList("Java", "Python", "C++");
List<String> upper = words.stream()
    .map(s -> s.toUpperCase())
    .collect(Collectors.toList());

变量捕获（闭包）

Lambda 可以从外部上下文“捕获”变量（前提是它们是 “有效” final）。这使得我们可以即时创建记住环境的函数：

int minLength = 3;
list.removeIf(s -> s.length() < minLength);

变量 minLength 在外部声明，但在 Lambda 内可用。

用于事件与回调的自然写法

button.addActionListener(e -> System.out.println("点击了按钮!"));

不再需要为了这一行而单独写一个类或匿名类。

简化测试

无需增殖类，就能快速传入“桩（stub）”：

doSomething(() -> System.out.println("测试处理器"));

2. Lambda 表达式的缺点与限制

与任何工具一样，它也有一些坑点。

调试上的困难

Lambda 是匿名函数；一旦出错，调用栈可能不那么直观。断点依然可用，但在冗长/嵌套的 Lambda 中，定位问题可能变得困难。

list.stream()
    .filter(s -> s.length() > 3)
    .map(s -> s.toUpperCase())
    .forEach(System.out::println);

有时，把链条“解开”成若干中间变量会更有帮助。

实现哪个接口不够直观

当存在接受不同函数式接口的重载时，编译器可能无法判断 Lambda 实现的是哪个接口（例如，返回 void 的 Runnable，或返回 String 的 Callable）。

void doSomething(Runnable r) { /* ... */ }
void doSomething(Callable<String> c) { /* ... */ }

// doSomething(() -> "Hello"); // 存在歧义!

不适合复杂逻辑

如果 Lambda 的主体增长到 3–5 行甚至更多（大量条件/循环），代码会降低可读性——最好把逻辑提取到具名方法中。

不佳：

list.removeIf(s -> s.length() > 3 && s.contains("Java") && s.startsWith("A") && ...);

更好：

list.removeIf(this::isComplexCondition);

private boolean isComplexCondition(String s) {
    return s.length() > 3 && s.contains("Java") && s.startsWith("A") && ...;
}

序列化方面的限制

Lambda 并非总是可序列化。如果需要在 JVM 之间传递逻辑（分布式系统），更可靠的做法是使用匿名类或具名类，或使用显式支持 Serializable 的接口。

作用域限制

如果外部方法中的变量不是 final 或“有效” final，则不能在 Lambda 中修改它们。

int count = 0;
list.forEach(s -> count++); // 编译器不会通过!

不适合复用

Lambda 更像是“一次性”函数。如果需要在多个地方复用该逻辑——请将其提取到具有清晰名称的方法或类中。

嵌套 Lambda 的困难

过深的嵌套（尤其在流/事件处理器中）会很快把代码变成“面条”。最好避免嵌套，或将其拆分为步骤。

何时使用 Lambda 表达式

• 短小、简单的操作：过滤、排序、集合转换、事件处理。
• 若 Lambda 超过 3–5 行——请提取到独立方法。
• 不要用 Lambda 承载复杂业务逻辑——给逻辑一个名称并配上注释。
• 避免沉迷于嵌套的 Lambda。
• 将重复出现的 Lambda 提取为方法（或静态方法），并使用引用形式 this::method 或 ClassName::method。
• 为 Lambda 内的参数起有意义的名字——这能提升可读性。

3. 实用建议

把复杂的链分解为若干阶段

与其写一条超长链，不如使用中间变量：

Stream<String> filtered = list.stream().filter(s -> s.length() > 3);
Stream<String> upper = filtered.map(String::toUpperCase);
upper.forEach(System.out::println);

对复杂条件使用具名方法

不要写冗长的 Lambda：

list.removeIf(s -> s.length() > 3 && s.contains("Java"));

更好：

list.removeIf(this::isJavaString);

private boolean isJavaString(String s) {
    return s.length() > 3 && s.contains("Java");
}

不要害怕写注释

如果某个 Lambda 不够直观——就在它前面加上注释：

// 删除所有以空格开头的字符串
list.removeIf(s -> s.startsWith(" "));

4. 使用 Lambda 表达式的常见错误

错误 1：Lambda 过于复杂。 新手往往试图把全部业务逻辑塞进一个 Lambda。结果就是 10 行的“怪物”，难读也难维护。别害怕把代码提取到方法中！

错误 2：作用域不清。 试图在 Lambda 内修改外部方法的变量——编译器会报错。请记住：变量必须是 final 或“有效” final。

错误 3：方法重载。 当存在两个接受不同函数式接口的重载时，编译器可能不知道你想调用哪一个。这种情况下请显式标注类型：

doSomething((Runnable) () -> System.out.println("Hello"));

错误 4：滥用嵌套 Lambda。 嵌套的 Lambda 会把代码变成不可读的“面条”。停下来，把部分代码提取到独立方法中。

错误 5：在需要完整对象的场景使用 Lambda。 如果需要重写多个方法、添加字段或实现非标准行为——请使用匿名类或具名类，而不是 Lambda。