在 Java 8 时代Lambda 表达式已经成为日常开发绕不开的语法。过去我们要为一个接口提供临时实现最常见的做法是写匿名内部类虽然它能解决“临时实现”的问题但代码冗长、可读性差。Lambda 表达式正是为了摆脱这种样板代码而出现同时把函数式编程思想带到了 Java 生态。这篇内容会围绕一条主线展开先看匿名内部类为什么会被替代再理解函数式接口和 Lambda 的运行机制然后通过最小案例完成“匿名内部类改造为 Lambda”的完整闭环最后补充编译报错、空指针、性能与生产落地时最值得注意的问题。适合已经掌握 Java 基础、准备系统学习 Java 8 函数式编程的开发者。1. 匿名内部类到底解决了什么问题又遗留下什么问题1.1 从接口实现看匿名内部类的价值在函数式编程还没有进入 Java 的时期如果想给一个接口提供临时实现主要有三种方式写一个独立实现类、在方法内部写命名局部类、使用匿名内部类一次性创建实例。其中匿名内部类最节省结构成本因为不需要单独建类文件也能就近访问外层变量所以它曾是 GUI 事件处理、多线程任务、集合比较器中最常见的实现方式。以Runnable为例Runnable task new Runnable() { Override public void run() { System.out.println(任务执行中); } }; new Thread(task).start();匿名内部类的价值是“用一次、写一次、不污染类结构”。它把接口实现和调用点放在一起避免了为只使用一次的类单独创建文件。在 Java 8 之前这种方式确实能解决需求开发者也已经习惯了它。1.2 匿名内部类在真实项目中的典型痛点随着项目代码量增长匿名内部类的结构成本开始超过它带来的便利。以 Java 8 之前的排序代码为例ListString names Arrays.asList(banana, apple, cherry); Collections.sort(names, new ComparatorString() { Override public int compare(String s1, String s2) { return s1.compareTo(s2); } });这段代码真正有用的逻辑其实只有一行return s1.compareTo(s2);。其他部分都在围绕接口签名填写基础设施。读代码的人需要先识别这是一个匿名类再找到重写的抽象方法才能推断这段代码到底想干什么。如果同一个类里有多个匿名内部类阅读成本会成倍增加。实际开发中匿名内部类主要有四个问题结构冗长一个new Comparator加Override要占好几行业务逻辑被淹没。作用域容易混淆this在匿名内部类中指向匿名类自身访问外部实例需要写成OuterClass.this这是初学者最常踩的坑。行为传递不直观方法参数是“需要传入一个比较器对象”而不是“需要传入一段比较逻辑”理解上多了一层抽象。命名与文件结构噪音大量匿名内部类会生成Outer$1.class、Outer$2.class等额外字节码文件排查问题时不够干净。这些问题并不是语言缺陷而是“用对象表达行为”这一设计在简洁性上的边界。比较逻辑本身只是一段行为却被强制包装成一个带类型的对象。1.3 为什么 Java 8 选择用 Lambda 来替代Lambda 表达式的本质是“把一段行为代码当作值来传递”。它不再要求开发者手动写出完整的匿名类结构而是通过 JVM 指令动态生成函数式接口的实例。Java 8 引入 Lambda 后上面的排序可以写成Collections.sort(names, (s1, s2) - s1.compareTo(s2));不再有new Comparator不再有Override剩下的就是真正的比较逻辑。Java 8 之所以能做到这一点是因为设计了“函数式接口”这个最小抽象一个接口只要只有一个抽象方法就可以用 Lambda 表达式作为它的实现。需要强调Lambda 并不是要消灭匿名内部类。当接口有多个抽象方法或者需要继承父类、创建具体类的子类时匿名内部类仍然不可替代。Lambda 针对的场景很明确接口只有一个抽象方法并且我们只需要使用这一次。下面用一张表对比匿名内部类与 Lambda维度匿名内部类Lambda 表达式适用接口任意接口、抽象类、具体类仅限函数式接口只有一个抽象方法语法成本需要完整写出new、Override只需要参数、箭头、方法体this指向指向匿名内部类对象指向外围实例编译产物生成独立的Outer$1.class通过invokedynamic运行期生成可读性逻辑被样板包裹逻辑更突出对象创建每次执行都新建对象可能复用行为由 JVM 决定2. 从 Lambda 语法到函数式接口必须先搞懂的两个概念2.1 函数式接口Lambda 的“契约”函数式接口是只有一个抽象方法的接口。这个概念很简单但它是理解 Lambda 的前提。Java 8 在java.util.function包中提供了一套标准函数式接口也保留了原有接口中满足条件的语义。判断一个接口是否是函数式接口最直接的方法是用FunctionalInterface注解标注。这个注解不是必须的但强烈推荐加它会在编译期检查接口是否真的只有一个抽象方法。FunctionalInterface public interface StringProcessor { String process(String input); }如果在这个接口里再添加一个抽象方法编译器会直接报错。需要注意Object类中的公共方法不算抽象方法默认方法也不算抽象方法。下面这个接口依然是函数式接口FunctionalInterface public interface Action { void doIt(); default void prepare() { System.out.println(准备); } String toString(); // 继承自 Object不算抽象方法 }函数式接口是 Lambda 的“契约”因为 Lambda 本身没有类型。它必须出现在一个期待函数式接口类型的上下文中编译器才能推断出参数类型和返回值。这个“期待类型”就是 Java 语言规范中的目标类型。2.2 Lambda 表达式的完整语法与省略规则Lambda 表达式的基本形式是(参数列表) - { 方法体 }完整写法示例BinaryOperatorInteger add (Integer a, Integer b) - { return a b; };为了减少样板代码Java 允许按规则省略一部分内容参数类型可以省略编译器会从函数式接口方法签名推断。只有一个参数时参数括号可以省略。方法体只有一条表达式时可以去掉{}和return关键字。空参数必须保留括号例如() - System.out.println(hello)。推荐写法BinaryOperatorInteger add (a, b) - a b; ConsumerString printer s - System.out.println(s); Runnable task () - System.out.println(任务);这里有一个容易混淆的地方方法体如果只有一条“语句”可以省略花括号但如果要写return则必须放在花括号块体内。下面这个写法会编译报错// 编译错误return 只能出现在块体中 FunctionString, Integer bad s - return s.length();正确写法FunctionString, Integer good s - s.length();省略参数类型以后代码虽然简洁但可读性在复杂场景下会下降。特别是多个参数类型相同的时候例如(a, b) - a.compareTo(b)读者需要结合上下文判断a、b到底是什么类型。实际项目中建议在复杂表达式中使用局部变量名来暗示类型也可以保留显式参数类型。2.3 常见函数式接口速查java.util.function包中常见的函数式接口如下表接口方法签名典型用途FunctionT, RR apply(T t)输入一个对象输出另一个对象ConsumerTvoid accept(T t)消费一个对象不返回结果SupplierTT get()提供一个对象不接收参数PredicateTboolean test(T t)条件判断UnaryOperatorTT apply(T t)同类型一元变换BinaryOperatorTT apply(T a, T b)同类型二元合并BiFunctionT, U, RR apply(T t, U u)两个输入一个输出使用这些接口时要注意它们的方法是否支持受检异常。Function、Consumer、Supplier等标准接口的方法声明中都没有throws Exception这意味着如果业务方法会抛受检异常不能直接放入 Lambda 体这个问题会在第 5 节详细讨论。3. 动手实操用 Runnable、Comparator 和自定义接口跑通改造闭环3.1 Runnable 演示线程代码如何从样板化变精简先从最简单的线程示例开始。学习环境可以直接在main方法中运行。匿名内部类写法Thread thread new Thread(new Runnable() { Override public void run() { System.out.println(Thread.currentThread().getName() 执行); } }); thread.start();Lambda 写法Thread thread new Thread(() - System.out.println(Thread.currentThread().getName() 执行)); thread.start();Runnable只有一个抽象方法run()参数为空所以 Lambda 写成() - ...。编译器知道Thread构造器需要Runnable于是把这段 Lambda 转换为Runnable实例。运行验证时控制台会输出类似Thread-0 执行的内容。每次执行线程名可能不同说明代码确实运行在新线程中。如果希望main线程等待新线程执行结束可以在start()后调用thread.join()但生产环境要谨慎使用join以免阻塞时间不可控。3.2 Comparator 演示排序逻辑从匿名类到 Lambda排序是工作中最常见的 Lambda 应用场景之一。匿名内部类写法ListString words Arrays.asList(pear, apple, banana); words.sort(new ComparatorString() { Override public int compare(String a, String b) { return a.compareTo(b); } });Lambda 写法ListString words Arrays.asList(pear, apple, banana); words.sort((a, b) - a.compareTo(b));更推荐使用方法引用words.sort(String::compareTo);这里需要解释ComparatorString的抽象方法返回intLambda 表达式a.compareTo(b)返回的也是int所以不需要手动处理装箱。List.sort是 Java 8 加入的默认方法排序是原地修改List本身不会返回新列表。运行验证System.out.println(words);预期输出[apple, banana, pear]3.3 自定义函数式接口理解参数、返回值、类型推断只看现成接口还不够建议自己定义一个函数式接口彻底理解参数、返回值和类型推断之间的关系。先定义接口FunctionalInterface public interface StringFormatter { String format(String prefix, String suffix, String content); }匿名内部类实现StringFormatter formatter new StringFormatter() { Override public String format(String prefix, String suffix, String content) { return prefix content suffix; } }; String result formatter.format(, , Lambda); System.out.println(result); // LambdaLambda 实现StringFormatter formatter (prefix, suffix, content) - prefix content suffix; String result formatter.format([, ], 函数式); System.out.println(result); // [函数式]三个参数的 Lambda 不能省略括号因为参数数量大于 1方法体只有一条表达式时表达式的求值结果会自动作为返回值不用写return。如果方法体有多行就需要用花括号块和return。自定义接口的价值在于它帮助开发者确认 Lambda 并不是只能用在 JDK 自带接口上而是任何一种“单抽象方法接口”都能享受 Lambda 语法。这也是为什么很多框架把FunctionalInterface用于事件监听器、回调接口和策略接口。3.4 编写并运行一个最小可验证示例把上面三个场景组合成一个可运行类方便读者直接复制测试import java.util.*; FunctionalInterface interface StringFormatter { String format(String prefix, String suffix, String content); } public class LambdaDemo { public static void main(String[] args) throws InterruptedException { Runnable task () - System.out.println(Thread.currentThread().getName() 通过Lambda启动); Thread thread new Thread(task); thread.start(); thread.join(); ListString words Arrays.asList(pear, apple, banana); words.sort((a, b) - a.compareTo(b)); System.out.println(排序结果: words); StringFormatter formatter (prefix, suffix, content) - prefix content suffix; System.out.println(格式化结果: formatter.format(, , Java 8)); } }编译运行javac LambdaDemo.java java LambdaDemo预期输出类似Thread-0 通过Lambda启动 排序结果: [apple, banana, pear] 格式化结果: Java 8在这个示例中thread.join()的作用是让主线程等待子线程结束后再继续保证输出顺序稳定。学习环境中可以加生产环境要根据业务判断是否需要等待。注意验证 Lambda 代码是否正常不能只看程序是否启动成功还要看三个分支的结果是否符合预期线程是否真的执行、排序是否真的改变、自定义函数式接口是否返回拼接结果。4. 底层原理Lambda 表达式不是语法糖那么简单4.1 javac 把 Lambda 编译成了什么很多教材把 Lambda 称为“语法糖”但这个说法并不完全准确。Lambda 不是简单地在编译期转换成匿名内部类而是通过invokedynamic指令在运行期生成函数式接口实现。用javap查看编译后的字节码可以直观看到差异javap -c -p LambdaDemo.class字节码中会出现类似这样的内容invokedynamic #7, 0 // InvokeDynamic #0:run:()Ljava/lang/Runnable;同时编译器会生成一个合成方法名字类似lambda$main$0。Lambda 体中的逻辑会被抽取到这个静态方法中然后由invokedynamic在运行时链接到函数式接口。我们可以从字节码中确认Lambda 并不是“创建一个匿名内部类对象的语法糖”而是把行为本身和方法实现分离。4.2 invokedynamic 在这个过程里做了什么invokedynamic原本是为 JVM 上的动态语言设计的指令。Java 8 把它用于 Lambda 实现核心流程如下编译器把 Lambda 体抽取为静态方法。在调用位置生成invokedynamic指令。首次执行时调用引导方法LambdaMetafactory.metafactory。引导方法根据函数式接口的类型信息生成实现类。后续执行时可以直接复用生成的结果。这个设计的好处是具体采用哪种实现策略由 JVM 在运行期决定。不同版本 JDK 可以针对 Lambda 做不同优化而不用改变 Java 源码语法。4.3 为什么 Lambda 每次执行不一定创建新对象匿名内部类每次执行new Runnable(){...}都会创建一个新对象。Lambda 则不一定。对于不捕获外围变量的 LambdaLambdaMetafactory可能返回一个可复用的单例对于捕获了外围变量的 Lambda由于需要保存捕获值通常需要创建一个新实例。可以写一个简单测试public class LambdaReferenceCheck { public static void main(String[] args) { Runnable r1 () - System.out.println(hello); Runnable r2 () - System.out.println(hello); System.out.println(r1 r2); } }这个输出通常为false因为两个 Lambda 表达式是不同的表达式即使方法体一样也可能生成不同实例。不要依赖这个行为做业务判断。生产代码不应该假设“Lambda 一定是单例”。String prefix ; FunctionString, String wrap s - prefix s;上面这段代码中的 Lambda 捕获了局部变量prefix运行时需要保存这个值所以通常会生成新实例来存储捕获状态。4.4 与匿名内部类的字节码差异匿名内部类编译后会生成独立的 class 文件例如Outer$1.class。这些文件包含完整的内部类结构。Lambda 编译后不会生成对应的Outer$1.class而是在运行期生成类似LambdaDemo$$Lambda$1.class的代理类。对比项匿名内部类Lambda编译期 class 文件生成Outer$1.class不生成固定 Lambda class 文件运行时实现直接实例化内部类通过LambdaMetafactory生成对象分配每次 new 都新建无捕获时可能复用捕获外围变量需要 final 或 effectively final同样需要this指向内部类自身外围实例为什么 Lambda 的this指向外围实例因为编译器把 Lambda 方法体抽取成了外围类的方法方法里的this自然就是外围类的实例。这一点对编写回调代码非常重要后面会进一步说明。5. 变量捕获、方法引用和常见错误实战中的高概率问题5.1 外围变量捕获effective finalLambda 可以访问外围方法或类的局部变量但被捕获的变量必须是 final 或 effectively final。所谓 effectively final就是变量初始化之后再也没有被重新赋值。int base 10; FunctionInteger, Integer addBase x - x base; System.out.println(addBase.apply(5)); // 15如果后续给base重新赋值int base 10; FunctionInteger, Integer addBase x - x base; base 20; // 编译错误编译器会报错local variables referenced from a lambda expression must be final or effectively final原因是 Lambda 捕获的是变量的值快照而不是变量本身。Java 设计者为了避免并发环境下的可见性问题以及简化闭包语义要求被捕获变量不可变。这也是许多函数式语言闭包的通用规则。5.2 方法引用类名::方法名的三种形式方法引用是 Lambda 的简洁写法适合方法体就是对某个方法调用的场景。常见形式有三种静态方法引用ClassName::staticMethod实例方法引用instance::instanceMethod特定类型实例方法引用ClassName::instanceMethod示例FunctionString, Integer parse1 Integer::parseInt; String str 42; SupplierInteger lenSupplier str::length; FunctionString, Integer lenFunction String::length;最后一行比较特殊String::length作为FunctionString, Integer表示把String类型的实例作为参数调用其length()方法返回int自动适配apply(String)返回Integer。这不是直观的“调用静态方法”而是未绑定的实例方法引用。方法引用能减少代码量但也会让类型推断变得更隐晦。如果一行代码里全是ClassName::method读者可能无法立刻判断目标类型建议在团队成员都熟悉之后再广泛使用。5.3 四种易错场景这里整理四个与 Lambda 强相关的高频问题每一个都可以在错误日志或编译报错中直接看到。场景一在 Lambda 体内修改局部变量int count 0; Runnable task () - count; // 编译错误原因count不是 effectively final。解决方案是使用AtomicInteger或把计数逻辑封装到对象中但更推荐重新设计代码避免在闭包内产生副作用。AtomicInteger count new AtomicInteger(0); Runnable task () - count.incrementAndGet();注意AtomicInteger提供了线程安全保证但它是一种可变对象仍然要谨慎设计并发逻辑。场景二在 for 循环里使用非 final 局部变量ListRunnable tasks new ArrayList(); for (int i 0; i 3; i) { tasks.add(() - System.out.println(i)); // 编译错误 }原因i在循环中不断变化不是 effectively final。解决方法是复制一份局部变量for (int i 0; i 3; i) { int index i; tasks.add(() - System.out.println(index)); }这里index在循环体内每次迭代都是新变量并且之后不再修改所以编译器认为它是 effectively final。运行后输出0 1 2符合预期。场景三错误理解 this 的指向匿名内部类中this指向匿名类对象Lambda 中this指向外围类对象。看下面的代码public class Outer { private String name outer; public Runnable getRunnable() { return () - System.out.println(this.name); } }这里的this.name能访问到Outer的name字段输出outer。如果改成匿名内部类public Runnable getRunnable() { return new Runnable() { Override public void run() { // 编译错误this.name 中的 this 是匿名内部类 System.out.println(this.name); } }; }匿名内部类没有name字段所以必须写成Outer.this.name。这正是两种写法最明显的行为差异。场景四返回 Lambda 导致闭包生命周期变长Lambda 可以捕获方法中的变量或外围实例并作为返回值传递给调用方。如果捕获的是外围类实例只要 Lambda 对象一直存活外围实例就无法被回收这可能造成内存泄漏。private ListString data new ArrayList(); public FunctionString, Boolean addAndContains() { return s - { data.add(s); return data.contains(s); }; }这里 Lambda 捕获了Outer实例的字段data只要返回的Function被长期持有Outer实例就不会被回收。生产环境中延迟任务、回调队列、事件监听器里要特别注意这一点。5.4 异常处理Lambda 体内的受检异常java.util.function中的函数式接口方法大多没有声明受检异常。例如Function.apply不抛出Exception所以业务代码不能直接把会抛受检异常的方法放进 Lambda 体FunctionString, String readFile path - { return Files.readString(Paths.get(path)); // 编译错误 };解决方案有三种在 Lambda 体内 try-catch并包装成运行时异常。自定义函数式接口方法签名中声明throws Exception。使用工具方法把受检异常统一转换为运行时异常。推荐先使用 try-catch 包裹并保留原始异常信息。下面是一个可复用的转换工具FunctionalInterface public interface ThrowingFunctionT, R { R apply(T t) throws Exception; } public static T, R FunctionT, R unchecked(ThrowingFunctionT, R fn) { return t - { try { return fn.apply(t); } catch (RuntimeException e) { throw e; } catch (Exception e) { throw new RuntimeException(e); } }; }使用方式FunctionString, String readFile unchecked(path - Files.readString(Paths.get(path)));这个模式很方便但它把受检异常包装成了运行时异常调用方在编译期不会得到异常提示。因此团队中需要约定只有非核心路径或异常处理策略已经明确时才使用这种封装。底层异常信息必须完整保留不要用throw new RuntimeException(e.getMessage())这种方式丢失堆栈。注意受检异常包装不是“万能药”。如果调用方需要根据异常类型做不同的恢复操作建议自定义函数式接口并声明抛出具体异常而不是一律包装成RuntimeException。6. 从入门到生产排查、性能、调试与最佳实践6.1 排查链路编译报错、空指针、行为异常Lambda 相关的问题可以分成三类编译期报错、运行期异常、行为不符合预期。排查时不要只盯语法还要看接口设计、变量捕获和并发状态。编译期报错常见关键字incompatible types: incompatible parameter types in lambda expression local variables referenced from a lambda expression must be final or effectively final method ... is not a functional interface排查顺序建议检查接口是否只有一个抽象方法。检查 Lambda 参数数量、类型和返回类型是否与接口方法匹配。检查被捕获的局部变量是否被重新赋值。检查是否缺少import java.util.function.*。检查泛型通配符是否影响了类型推断例如Comparator? super T。运行期空指针和异常空指针NullPointerException常见于 Lambda 内调用捕获变量的方法但这个变量创建时为 null。排查时先看捕获点再看调用链。集合流中元素为 null例如list.stream().map(String::length)遇到 null 元素会抛 NPE。并发修改共享集合多个线程同时往一个ArrayList或HashMap写入可能抛出ConcurrentModificationException或产生数据错乱。排查时看是否使用了线程安全集合。下面用表格整理常见问题问题现象常见原因检查方式处理建议编译报“must be final or effectively final”捕获了被修改的局部变量检查变量赋值点复制一份局部变量或重构编译报“invalid functional interface”接口有多个抽象方法查看接口声明加FunctionalInterface或拆分接口运行期 NPE捕获对象或集合元素为 null打印调用链增加空值保护明确空值约定结果不符合预期依赖了执行顺序或共享可变状态检查是否有副作用改为无状态运算或同步控制内存增长过快Lambda 捕获了重量级对象分析引用关系避免在长生命周期任务中捕获大对象6.2 学习环境快速验证 vs 生产环境使用注意学习环境只需要 JDK 8 或更高版本。本文示例在 JDK 8、11、17 都能编译运行。IDE 可以在 IntelliJ IDEA 或 Eclipse 中把项目语言级别设置为 8 以上。快速验证方式javac LambdaDemo.java java LambdaDemo生产环境需要注意的点和学习环境很不一样不要在高频路径中使用反复捕获大对象的 Lambda。例如在循环中每次创建捕获了大型上下文对象的 Lambda既增加对象分配也可能影响 GC。Lambda 内部不要执行长时间阻塞操作。如果把它提交到固定线程池阻塞时间过久会耗尽线程。使用Stream时要注意惰性求值。filter、map是中间操作只有遇到终端操作才会真正执行。如果只用filter不接终端操作代码不会执行对应逻辑。简单循环可能比 Stream 更合适。比如需要break提前终止、需要操作索引、嵌套循环逻辑复杂时传统 for 循环更直观。场景推荐方式原因简单映射、过滤、归约Stream Lambda表达清晰需要提前终止循环传统 forStream 没有统一的 break 操作需要操作索引IntStream 或传统循环传统循环更直观嵌套循环且逻辑复杂提取方法后再选择避免嵌套可读性恶化高频短调用先写普通方法再决定便于调试和解析堆栈生产环境还要考虑日志。Lambda 方法体在堆栈中显示为LambdaDemo.lambda$main$0不如普通方法名直观。复杂 Lambda 建议提取成命名方法再使用方法引用例如list.stream().map(this::parseItem)这样日志和堆栈会清晰很多。6.3 代码审查清单和重构建议把匿名内部类改为 Lambda 不是单纯“删模板代码”而是调整代码的表达方式。下面的清单可以在代码评审时直接复用接口是否标注了FunctionalInterface确认只有一个抽象方法。每个 Lambda 是否只做一件事是否足够短超过 3 行时是否提取为方法。参数类型省略后代码是否仍然可读复杂表达式是否需要显式类型。是否捕获了不必要的外部实例或局部变量是否会造成生命周期过长。是否修改了被捕获的局部变量如果有必须改为 effectively final。异常是否被正确处理是否保留原始异常堆栈。并发环境下是否有共享可变状态是否使用线程安全容器。是否过度使用方法引用导致类型推断困难。能否用传统 for 循环替代并提高可读性保持简单是第一位。重构建议先从最简单的Runnable和Comparator开始替换。每次替换一个类文件运行一次相关单元测试。如果匿名内部类包含多个方法不能直接替换成 Lambda应保留匿名类或将方法拆解。超过 3 行的 Lambda 优先提取为命名方法再使用方法引用。团队规范中统一是否使用受检异常封装工具避免每个开发各自封一套。6.4 下一步Stream、Optional、方法引用这一篇是函数式编程入门的第一篇后续可以沿着几条路径继续深入Stream的惰性求值、中间操作与终端操作。Optional如何代替null判断以及它适合解决什么问题。Collectors的分组、分区、聚合。CompletableFuture与函数式接口的结合。LambdaMetafactory的更多内部机制适合对 JVM 感兴趣时阅读。学习路径建议掌握函数式接口和 Lambda 语法先能正确写出、读懂 Lambda。熟悉java.util.function和Stream常用操作。挑一个旧项目统计有多少匿名内部类可以替换成 Lambda逐个替换并运行测试。阅读java.util.stream.Collectors源码理解收集过程。在代码评审中主动关注函数式代码的安全性和性能。实际项目中不要把“用 Lambda 替换所有匿名内部类”当作目标。更值得追求的是在合适的场景用更短的代码表达清晰的行为同时了解它背后的运行机制避免为语法上的简洁付出维护上的代价。可以从一个最小的排序方法开始把匿名内部类改成 Lambda再逐步扩展到回调、流处理和自定义函数式接口这样就能建立对 Java 8 函数式编程更完整的认识。
Java 8 Lambda表达式：从匿名内部类到函数式编程
在 Java 8 时代Lambda 表达式已经成为日常开发绕不开的语法。过去我们要为一个接口提供临时实现最常见的做法是写匿名内部类虽然它能解决“临时实现”的问题但代码冗长、可读性差。Lambda 表达式正是为了摆脱这种样板代码而出现同时把函数式编程思想带到了 Java 生态。这篇内容会围绕一条主线展开先看匿名内部类为什么会被替代再理解函数式接口和 Lambda 的运行机制然后通过最小案例完成“匿名内部类改造为 Lambda”的完整闭环最后补充编译报错、空指针、性能与生产落地时最值得注意的问题。适合已经掌握 Java 基础、准备系统学习 Java 8 函数式编程的开发者。1. 匿名内部类到底解决了什么问题又遗留下什么问题1.1 从接口实现看匿名内部类的价值在函数式编程还没有进入 Java 的时期如果想给一个接口提供临时实现主要有三种方式写一个独立实现类、在方法内部写命名局部类、使用匿名内部类一次性创建实例。其中匿名内部类最节省结构成本因为不需要单独建类文件也能就近访问外层变量所以它曾是 GUI 事件处理、多线程任务、集合比较器中最常见的实现方式。以Runnable为例Runnable task new Runnable() { Override public void run() { System.out.println(任务执行中); } }; new Thread(task).start();匿名内部类的价值是“用一次、写一次、不污染类结构”。它把接口实现和调用点放在一起避免了为只使用一次的类单独创建文件。在 Java 8 之前这种方式确实能解决需求开发者也已经习惯了它。1.2 匿名内部类在真实项目中的典型痛点随着项目代码量增长匿名内部类的结构成本开始超过它带来的便利。以 Java 8 之前的排序代码为例ListString names Arrays.asList(banana, apple, cherry); Collections.sort(names, new ComparatorString() { Override public int compare(String s1, String s2) { return s1.compareTo(s2); } });这段代码真正有用的逻辑其实只有一行return s1.compareTo(s2);。其他部分都在围绕接口签名填写基础设施。读代码的人需要先识别这是一个匿名类再找到重写的抽象方法才能推断这段代码到底想干什么。如果同一个类里有多个匿名内部类阅读成本会成倍增加。实际开发中匿名内部类主要有四个问题结构冗长一个new Comparator加Override要占好几行业务逻辑被淹没。作用域容易混淆this在匿名内部类中指向匿名类自身访问外部实例需要写成OuterClass.this这是初学者最常踩的坑。行为传递不直观方法参数是“需要传入一个比较器对象”而不是“需要传入一段比较逻辑”理解上多了一层抽象。命名与文件结构噪音大量匿名内部类会生成Outer$1.class、Outer$2.class等额外字节码文件排查问题时不够干净。这些问题并不是语言缺陷而是“用对象表达行为”这一设计在简洁性上的边界。比较逻辑本身只是一段行为却被强制包装成一个带类型的对象。1.3 为什么 Java 8 选择用 Lambda 来替代Lambda 表达式的本质是“把一段行为代码当作值来传递”。它不再要求开发者手动写出完整的匿名类结构而是通过 JVM 指令动态生成函数式接口的实例。Java 8 引入 Lambda 后上面的排序可以写成Collections.sort(names, (s1, s2) - s1.compareTo(s2));不再有new Comparator不再有Override剩下的就是真正的比较逻辑。Java 8 之所以能做到这一点是因为设计了“函数式接口”这个最小抽象一个接口只要只有一个抽象方法就可以用 Lambda 表达式作为它的实现。需要强调Lambda 并不是要消灭匿名内部类。当接口有多个抽象方法或者需要继承父类、创建具体类的子类时匿名内部类仍然不可替代。Lambda 针对的场景很明确接口只有一个抽象方法并且我们只需要使用这一次。下面用一张表对比匿名内部类与 Lambda维度匿名内部类Lambda 表达式适用接口任意接口、抽象类、具体类仅限函数式接口只有一个抽象方法语法成本需要完整写出new、Override只需要参数、箭头、方法体this指向指向匿名内部类对象指向外围实例编译产物生成独立的Outer$1.class通过invokedynamic运行期生成可读性逻辑被样板包裹逻辑更突出对象创建每次执行都新建对象可能复用行为由 JVM 决定2. 从 Lambda 语法到函数式接口必须先搞懂的两个概念2.1 函数式接口Lambda 的“契约”函数式接口是只有一个抽象方法的接口。这个概念很简单但它是理解 Lambda 的前提。Java 8 在java.util.function包中提供了一套标准函数式接口也保留了原有接口中满足条件的语义。判断一个接口是否是函数式接口最直接的方法是用FunctionalInterface注解标注。这个注解不是必须的但强烈推荐加它会在编译期检查接口是否真的只有一个抽象方法。FunctionalInterface public interface StringProcessor { String process(String input); }如果在这个接口里再添加一个抽象方法编译器会直接报错。需要注意Object类中的公共方法不算抽象方法默认方法也不算抽象方法。下面这个接口依然是函数式接口FunctionalInterface public interface Action { void doIt(); default void prepare() { System.out.println(准备); } String toString(); // 继承自 Object不算抽象方法 }函数式接口是 Lambda 的“契约”因为 Lambda 本身没有类型。它必须出现在一个期待函数式接口类型的上下文中编译器才能推断出参数类型和返回值。这个“期待类型”就是 Java 语言规范中的目标类型。2.2 Lambda 表达式的完整语法与省略规则Lambda 表达式的基本形式是(参数列表) - { 方法体 }完整写法示例BinaryOperatorInteger add (Integer a, Integer b) - { return a b; };为了减少样板代码Java 允许按规则省略一部分内容参数类型可以省略编译器会从函数式接口方法签名推断。只有一个参数时参数括号可以省略。方法体只有一条表达式时可以去掉{}和return关键字。空参数必须保留括号例如() - System.out.println(hello)。推荐写法BinaryOperatorInteger add (a, b) - a b; ConsumerString printer s - System.out.println(s); Runnable task () - System.out.println(任务);这里有一个容易混淆的地方方法体如果只有一条“语句”可以省略花括号但如果要写return则必须放在花括号块体内。下面这个写法会编译报错// 编译错误return 只能出现在块体中 FunctionString, Integer bad s - return s.length();正确写法FunctionString, Integer good s - s.length();省略参数类型以后代码虽然简洁但可读性在复杂场景下会下降。特别是多个参数类型相同的时候例如(a, b) - a.compareTo(b)读者需要结合上下文判断a、b到底是什么类型。实际项目中建议在复杂表达式中使用局部变量名来暗示类型也可以保留显式参数类型。2.3 常见函数式接口速查java.util.function包中常见的函数式接口如下表接口方法签名典型用途FunctionT, RR apply(T t)输入一个对象输出另一个对象ConsumerTvoid accept(T t)消费一个对象不返回结果SupplierTT get()提供一个对象不接收参数PredicateTboolean test(T t)条件判断UnaryOperatorTT apply(T t)同类型一元变换BinaryOperatorTT apply(T a, T b)同类型二元合并BiFunctionT, U, RR apply(T t, U u)两个输入一个输出使用这些接口时要注意它们的方法是否支持受检异常。Function、Consumer、Supplier等标准接口的方法声明中都没有throws Exception这意味着如果业务方法会抛受检异常不能直接放入 Lambda 体这个问题会在第 5 节详细讨论。3. 动手实操用 Runnable、Comparator 和自定义接口跑通改造闭环3.1 Runnable 演示线程代码如何从样板化变精简先从最简单的线程示例开始。学习环境可以直接在main方法中运行。匿名内部类写法Thread thread new Thread(new Runnable() { Override public void run() { System.out.println(Thread.currentThread().getName() 执行); } }); thread.start();Lambda 写法Thread thread new Thread(() - System.out.println(Thread.currentThread().getName() 执行)); thread.start();Runnable只有一个抽象方法run()参数为空所以 Lambda 写成() - ...。编译器知道Thread构造器需要Runnable于是把这段 Lambda 转换为Runnable实例。运行验证时控制台会输出类似Thread-0 执行的内容。每次执行线程名可能不同说明代码确实运行在新线程中。如果希望main线程等待新线程执行结束可以在start()后调用thread.join()但生产环境要谨慎使用join以免阻塞时间不可控。3.2 Comparator 演示排序逻辑从匿名类到 Lambda排序是工作中最常见的 Lambda 应用场景之一。匿名内部类写法ListString words Arrays.asList(pear, apple, banana); words.sort(new ComparatorString() { Override public int compare(String a, String b) { return a.compareTo(b); } });Lambda 写法ListString words Arrays.asList(pear, apple, banana); words.sort((a, b) - a.compareTo(b));更推荐使用方法引用words.sort(String::compareTo);这里需要解释ComparatorString的抽象方法返回intLambda 表达式a.compareTo(b)返回的也是int所以不需要手动处理装箱。List.sort是 Java 8 加入的默认方法排序是原地修改List本身不会返回新列表。运行验证System.out.println(words);预期输出[apple, banana, pear]3.3 自定义函数式接口理解参数、返回值、类型推断只看现成接口还不够建议自己定义一个函数式接口彻底理解参数、返回值和类型推断之间的关系。先定义接口FunctionalInterface public interface StringFormatter { String format(String prefix, String suffix, String content); }匿名内部类实现StringFormatter formatter new StringFormatter() { Override public String format(String prefix, String suffix, String content) { return prefix content suffix; } }; String result formatter.format(, , Lambda); System.out.println(result); // LambdaLambda 实现StringFormatter formatter (prefix, suffix, content) - prefix content suffix; String result formatter.format([, ], 函数式); System.out.println(result); // [函数式]三个参数的 Lambda 不能省略括号因为参数数量大于 1方法体只有一条表达式时表达式的求值结果会自动作为返回值不用写return。如果方法体有多行就需要用花括号块和return。自定义接口的价值在于它帮助开发者确认 Lambda 并不是只能用在 JDK 自带接口上而是任何一种“单抽象方法接口”都能享受 Lambda 语法。这也是为什么很多框架把FunctionalInterface用于事件监听器、回调接口和策略接口。3.4 编写并运行一个最小可验证示例把上面三个场景组合成一个可运行类方便读者直接复制测试import java.util.*; FunctionalInterface interface StringFormatter { String format(String prefix, String suffix, String content); } public class LambdaDemo { public static void main(String[] args) throws InterruptedException { Runnable task () - System.out.println(Thread.currentThread().getName() 通过Lambda启动); Thread thread new Thread(task); thread.start(); thread.join(); ListString words Arrays.asList(pear, apple, banana); words.sort((a, b) - a.compareTo(b)); System.out.println(排序结果: words); StringFormatter formatter (prefix, suffix, content) - prefix content suffix; System.out.println(格式化结果: formatter.format(, , Java 8)); } }编译运行javac LambdaDemo.java java LambdaDemo预期输出类似Thread-0 通过Lambda启动 排序结果: [apple, banana, pear] 格式化结果: Java 8在这个示例中thread.join()的作用是让主线程等待子线程结束后再继续保证输出顺序稳定。学习环境中可以加生产环境要根据业务判断是否需要等待。注意验证 Lambda 代码是否正常不能只看程序是否启动成功还要看三个分支的结果是否符合预期线程是否真的执行、排序是否真的改变、自定义函数式接口是否返回拼接结果。4. 底层原理Lambda 表达式不是语法糖那么简单4.1 javac 把 Lambda 编译成了什么很多教材把 Lambda 称为“语法糖”但这个说法并不完全准确。Lambda 不是简单地在编译期转换成匿名内部类而是通过invokedynamic指令在运行期生成函数式接口实现。用javap查看编译后的字节码可以直观看到差异javap -c -p LambdaDemo.class字节码中会出现类似这样的内容invokedynamic #7, 0 // InvokeDynamic #0:run:()Ljava/lang/Runnable;同时编译器会生成一个合成方法名字类似lambda$main$0。Lambda 体中的逻辑会被抽取到这个静态方法中然后由invokedynamic在运行时链接到函数式接口。我们可以从字节码中确认Lambda 并不是“创建一个匿名内部类对象的语法糖”而是把行为本身和方法实现分离。4.2 invokedynamic 在这个过程里做了什么invokedynamic原本是为 JVM 上的动态语言设计的指令。Java 8 把它用于 Lambda 实现核心流程如下编译器把 Lambda 体抽取为静态方法。在调用位置生成invokedynamic指令。首次执行时调用引导方法LambdaMetafactory.metafactory。引导方法根据函数式接口的类型信息生成实现类。后续执行时可以直接复用生成的结果。这个设计的好处是具体采用哪种实现策略由 JVM 在运行期决定。不同版本 JDK 可以针对 Lambda 做不同优化而不用改变 Java 源码语法。4.3 为什么 Lambda 每次执行不一定创建新对象匿名内部类每次执行new Runnable(){...}都会创建一个新对象。Lambda 则不一定。对于不捕获外围变量的 LambdaLambdaMetafactory可能返回一个可复用的单例对于捕获了外围变量的 Lambda由于需要保存捕获值通常需要创建一个新实例。可以写一个简单测试public class LambdaReferenceCheck { public static void main(String[] args) { Runnable r1 () - System.out.println(hello); Runnable r2 () - System.out.println(hello); System.out.println(r1 r2); } }这个输出通常为false因为两个 Lambda 表达式是不同的表达式即使方法体一样也可能生成不同实例。不要依赖这个行为做业务判断。生产代码不应该假设“Lambda 一定是单例”。String prefix ; FunctionString, String wrap s - prefix s;上面这段代码中的 Lambda 捕获了局部变量prefix运行时需要保存这个值所以通常会生成新实例来存储捕获状态。4.4 与匿名内部类的字节码差异匿名内部类编译后会生成独立的 class 文件例如Outer$1.class。这些文件包含完整的内部类结构。Lambda 编译后不会生成对应的Outer$1.class而是在运行期生成类似LambdaDemo$$Lambda$1.class的代理类。对比项匿名内部类Lambda编译期 class 文件生成Outer$1.class不生成固定 Lambda class 文件运行时实现直接实例化内部类通过LambdaMetafactory生成对象分配每次 new 都新建无捕获时可能复用捕获外围变量需要 final 或 effectively final同样需要this指向内部类自身外围实例为什么 Lambda 的this指向外围实例因为编译器把 Lambda 方法体抽取成了外围类的方法方法里的this自然就是外围类的实例。这一点对编写回调代码非常重要后面会进一步说明。5. 变量捕获、方法引用和常见错误实战中的高概率问题5.1 外围变量捕获effective finalLambda 可以访问外围方法或类的局部变量但被捕获的变量必须是 final 或 effectively final。所谓 effectively final就是变量初始化之后再也没有被重新赋值。int base 10; FunctionInteger, Integer addBase x - x base; System.out.println(addBase.apply(5)); // 15如果后续给base重新赋值int base 10; FunctionInteger, Integer addBase x - x base; base 20; // 编译错误编译器会报错local variables referenced from a lambda expression must be final or effectively final原因是 Lambda 捕获的是变量的值快照而不是变量本身。Java 设计者为了避免并发环境下的可见性问题以及简化闭包语义要求被捕获变量不可变。这也是许多函数式语言闭包的通用规则。5.2 方法引用类名::方法名的三种形式方法引用是 Lambda 的简洁写法适合方法体就是对某个方法调用的场景。常见形式有三种静态方法引用ClassName::staticMethod实例方法引用instance::instanceMethod特定类型实例方法引用ClassName::instanceMethod示例FunctionString, Integer parse1 Integer::parseInt; String str 42; SupplierInteger lenSupplier str::length; FunctionString, Integer lenFunction String::length;最后一行比较特殊String::length作为FunctionString, Integer表示把String类型的实例作为参数调用其length()方法返回int自动适配apply(String)返回Integer。这不是直观的“调用静态方法”而是未绑定的实例方法引用。方法引用能减少代码量但也会让类型推断变得更隐晦。如果一行代码里全是ClassName::method读者可能无法立刻判断目标类型建议在团队成员都熟悉之后再广泛使用。5.3 四种易错场景这里整理四个与 Lambda 强相关的高频问题每一个都可以在错误日志或编译报错中直接看到。场景一在 Lambda 体内修改局部变量int count 0; Runnable task () - count; // 编译错误原因count不是 effectively final。解决方案是使用AtomicInteger或把计数逻辑封装到对象中但更推荐重新设计代码避免在闭包内产生副作用。AtomicInteger count new AtomicInteger(0); Runnable task () - count.incrementAndGet();注意AtomicInteger提供了线程安全保证但它是一种可变对象仍然要谨慎设计并发逻辑。场景二在 for 循环里使用非 final 局部变量ListRunnable tasks new ArrayList(); for (int i 0; i 3; i) { tasks.add(() - System.out.println(i)); // 编译错误 }原因i在循环中不断变化不是 effectively final。解决方法是复制一份局部变量for (int i 0; i 3; i) { int index i; tasks.add(() - System.out.println(index)); }这里index在循环体内每次迭代都是新变量并且之后不再修改所以编译器认为它是 effectively final。运行后输出0 1 2符合预期。场景三错误理解 this 的指向匿名内部类中this指向匿名类对象Lambda 中this指向外围类对象。看下面的代码public class Outer { private String name outer; public Runnable getRunnable() { return () - System.out.println(this.name); } }这里的this.name能访问到Outer的name字段输出outer。如果改成匿名内部类public Runnable getRunnable() { return new Runnable() { Override public void run() { // 编译错误this.name 中的 this 是匿名内部类 System.out.println(this.name); } }; }匿名内部类没有name字段所以必须写成Outer.this.name。这正是两种写法最明显的行为差异。场景四返回 Lambda 导致闭包生命周期变长Lambda 可以捕获方法中的变量或外围实例并作为返回值传递给调用方。如果捕获的是外围类实例只要 Lambda 对象一直存活外围实例就无法被回收这可能造成内存泄漏。private ListString data new ArrayList(); public FunctionString, Boolean addAndContains() { return s - { data.add(s); return data.contains(s); }; }这里 Lambda 捕获了Outer实例的字段data只要返回的Function被长期持有Outer实例就不会被回收。生产环境中延迟任务、回调队列、事件监听器里要特别注意这一点。5.4 异常处理Lambda 体内的受检异常java.util.function中的函数式接口方法大多没有声明受检异常。例如Function.apply不抛出Exception所以业务代码不能直接把会抛受检异常的方法放进 Lambda 体FunctionString, String readFile path - { return Files.readString(Paths.get(path)); // 编译错误 };解决方案有三种在 Lambda 体内 try-catch并包装成运行时异常。自定义函数式接口方法签名中声明throws Exception。使用工具方法把受检异常统一转换为运行时异常。推荐先使用 try-catch 包裹并保留原始异常信息。下面是一个可复用的转换工具FunctionalInterface public interface ThrowingFunctionT, R { R apply(T t) throws Exception; } public static T, R FunctionT, R unchecked(ThrowingFunctionT, R fn) { return t - { try { return fn.apply(t); } catch (RuntimeException e) { throw e; } catch (Exception e) { throw new RuntimeException(e); } }; }使用方式FunctionString, String readFile unchecked(path - Files.readString(Paths.get(path)));这个模式很方便但它把受检异常包装成了运行时异常调用方在编译期不会得到异常提示。因此团队中需要约定只有非核心路径或异常处理策略已经明确时才使用这种封装。底层异常信息必须完整保留不要用throw new RuntimeException(e.getMessage())这种方式丢失堆栈。注意受检异常包装不是“万能药”。如果调用方需要根据异常类型做不同的恢复操作建议自定义函数式接口并声明抛出具体异常而不是一律包装成RuntimeException。6. 从入门到生产排查、性能、调试与最佳实践6.1 排查链路编译报错、空指针、行为异常Lambda 相关的问题可以分成三类编译期报错、运行期异常、行为不符合预期。排查时不要只盯语法还要看接口设计、变量捕获和并发状态。编译期报错常见关键字incompatible types: incompatible parameter types in lambda expression local variables referenced from a lambda expression must be final or effectively final method ... is not a functional interface排查顺序建议检查接口是否只有一个抽象方法。检查 Lambda 参数数量、类型和返回类型是否与接口方法匹配。检查被捕获的局部变量是否被重新赋值。检查是否缺少import java.util.function.*。检查泛型通配符是否影响了类型推断例如Comparator? super T。运行期空指针和异常空指针NullPointerException常见于 Lambda 内调用捕获变量的方法但这个变量创建时为 null。排查时先看捕获点再看调用链。集合流中元素为 null例如list.stream().map(String::length)遇到 null 元素会抛 NPE。并发修改共享集合多个线程同时往一个ArrayList或HashMap写入可能抛出ConcurrentModificationException或产生数据错乱。排查时看是否使用了线程安全集合。下面用表格整理常见问题问题现象常见原因检查方式处理建议编译报“must be final or effectively final”捕获了被修改的局部变量检查变量赋值点复制一份局部变量或重构编译报“invalid functional interface”接口有多个抽象方法查看接口声明加FunctionalInterface或拆分接口运行期 NPE捕获对象或集合元素为 null打印调用链增加空值保护明确空值约定结果不符合预期依赖了执行顺序或共享可变状态检查是否有副作用改为无状态运算或同步控制内存增长过快Lambda 捕获了重量级对象分析引用关系避免在长生命周期任务中捕获大对象6.2 学习环境快速验证 vs 生产环境使用注意学习环境只需要 JDK 8 或更高版本。本文示例在 JDK 8、11、17 都能编译运行。IDE 可以在 IntelliJ IDEA 或 Eclipse 中把项目语言级别设置为 8 以上。快速验证方式javac LambdaDemo.java java LambdaDemo生产环境需要注意的点和学习环境很不一样不要在高频路径中使用反复捕获大对象的 Lambda。例如在循环中每次创建捕获了大型上下文对象的 Lambda既增加对象分配也可能影响 GC。Lambda 内部不要执行长时间阻塞操作。如果把它提交到固定线程池阻塞时间过久会耗尽线程。使用Stream时要注意惰性求值。filter、map是中间操作只有遇到终端操作才会真正执行。如果只用filter不接终端操作代码不会执行对应逻辑。简单循环可能比 Stream 更合适。比如需要break提前终止、需要操作索引、嵌套循环逻辑复杂时传统 for 循环更直观。场景推荐方式原因简单映射、过滤、归约Stream Lambda表达清晰需要提前终止循环传统 forStream 没有统一的 break 操作需要操作索引IntStream 或传统循环传统循环更直观嵌套循环且逻辑复杂提取方法后再选择避免嵌套可读性恶化高频短调用先写普通方法再决定便于调试和解析堆栈生产环境还要考虑日志。Lambda 方法体在堆栈中显示为LambdaDemo.lambda$main$0不如普通方法名直观。复杂 Lambda 建议提取成命名方法再使用方法引用例如list.stream().map(this::parseItem)这样日志和堆栈会清晰很多。6.3 代码审查清单和重构建议把匿名内部类改为 Lambda 不是单纯“删模板代码”而是调整代码的表达方式。下面的清单可以在代码评审时直接复用接口是否标注了FunctionalInterface确认只有一个抽象方法。每个 Lambda 是否只做一件事是否足够短超过 3 行时是否提取为方法。参数类型省略后代码是否仍然可读复杂表达式是否需要显式类型。是否捕获了不必要的外部实例或局部变量是否会造成生命周期过长。是否修改了被捕获的局部变量如果有必须改为 effectively final。异常是否被正确处理是否保留原始异常堆栈。并发环境下是否有共享可变状态是否使用线程安全容器。是否过度使用方法引用导致类型推断困难。能否用传统 for 循环替代并提高可读性保持简单是第一位。重构建议先从最简单的Runnable和Comparator开始替换。每次替换一个类文件运行一次相关单元测试。如果匿名内部类包含多个方法不能直接替换成 Lambda应保留匿名类或将方法拆解。超过 3 行的 Lambda 优先提取为命名方法再使用方法引用。团队规范中统一是否使用受检异常封装工具避免每个开发各自封一套。6.4 下一步Stream、Optional、方法引用这一篇是函数式编程入门的第一篇后续可以沿着几条路径继续深入Stream的惰性求值、中间操作与终端操作。Optional如何代替null判断以及它适合解决什么问题。Collectors的分组、分区、聚合。CompletableFuture与函数式接口的结合。LambdaMetafactory的更多内部机制适合对 JVM 感兴趣时阅读。学习路径建议掌握函数式接口和 Lambda 语法先能正确写出、读懂 Lambda。熟悉java.util.function和Stream常用操作。挑一个旧项目统计有多少匿名内部类可以替换成 Lambda逐个替换并运行测试。阅读java.util.stream.Collectors源码理解收集过程。在代码评审中主动关注函数式代码的安全性和性能。实际项目中不要把“用 Lambda 替换所有匿名内部类”当作目标。更值得追求的是在合适的场景用更短的代码表达清晰的行为同时了解它背后的运行机制避免为语法上的简洁付出维护上的代价。可以从一个最小的排序方法开始把匿名内部类改成 Lambda再逐步扩展到回调、流处理和自定义函数式接口这样就能建立对 Java 8 函数式编程更完整的认识。
