Learning Path

JDK 1.8 新特性实战：从默认方法到函数式编程

本文系统梳理了JDK 1.8的核心新特性，包括接口默认方法、Lambda表达式、函数式接口、方法引用、内置函数式接口（如Function、Supplier）以及Stream API的基础。通过41个实战案例，帮助开发者快速掌握并应用这些特性，提升编码效率与代码简洁性。

进阶6 张卡约 90 分钟发布于 2026年6月24日

路径目标

JDK 1.8 新特性实战：从默认方法到函数式编程

一条基于实战案例的学习路径，从理解JDK 1.8对抽象设计的根本性改变开始，逐步掌握Lambda表达式的类型推断、函数式接口的规范、方法与构造函数的便捷引用，并深入运用内置的Function、Supplier等接口，最终为使用Stream等更高级特性打下基础。

6 张知识卡6 个诊断问题6 个边界答案6 个记忆锚点

外部资料

对比jdk1.7抽象类与jdk1.8接口默认方法的设计差异

在jdk1.8之前，接口只能定义方法，共享的实现必须放在抽象类中。jdk1.8引入了使用default关键字在接口中定义默认方法的能力。这改变了抽象设计，使接口可以提供有默认行为的方法实现，类似于抽象类，但避免了单继承的限制。实现类可以直接调用默认方法，也可以选择重写。注意，这可能导致类似多重继承的菱形问题。

诊断题

在jdk1.8中，为什么要在接口中引入默认方法（default method）？它解决了接口设计中的什么问题，并可能带来什么新挑战？

答案骨架

我能解释：1) 在jdk1.8之前，接口方法必须全部是抽象的，共享的通用实现只能放在抽象类中，这限制了接口的演进；2) 使用default关键字定义的方法提供了默认实现，允许向现有接口添加新功能而不破坏已有的实现类；3) 这类似于抽象类，但允许一个类实现多个接口，避免了单继承的限制，但也引入了多重继承的冲突风险。

边界追问

如果一个类同时实现了两个接口，这两个接口有一个同名的默认方法，会发生什么？

边界答案

在这种情况下，编译器会报错，因为出现了二义性。解决方法是：1) 在实现类中必须重写该冲突的方法，明确指定使用哪一个，或者提供自己的实现；2) 可以使用InterfaceName.super.methodName()的语法来调用指定接口的默认实现。这体现了菱形继承问题的处理原则。

记忆锚点

接口终于能‘自带干粮’（默认实现），但‘多吃一家’（多实现）时，饭要自己端（重写解决冲突）。

落地场景

定义接口IFormula，包含抽象方法calculate(int a)和默认方法sqrt(int a)（返回Math.sqrt(a)）。一个匿名内部类实现了calculate后，可以直接调用formula.sqrt(2)获得结果。

打开资料

外部资料

使用Lambda表达式简化匿名内部类并理解其类型推断

Lambda表达式是JDK 1.8引入的简洁语法，用于实现函数式接口（只有一个抽象方法的接口）。它替代了冗长的匿名内部类写法。例如，Collections.sort的Comparator实现可以从多行匿名类简化为(a, b) -> b.compareTo(a)。编译器通过目标类型（函数式接口的类型）进行类型推断，确定Lambda参数和返回值的类型。

诊断题

Lambda表达式是如何实现代码简化的？它的使用前提是类型系统中的哪个关键概念？请举例对比传统写法与Lambda写法。

答案骨架

我能说明：1) Lambda表达式本质上是函数式接口的匿名实现，语法为(参数列表) -> {方法体}，当方法体只有一行时可省略花括号和return；2) 使用前提是存在一个函数式接口（如Comparator<T>）作为目标类型；3) 编译器根据目标类型推断Lambda参数的类型，实现类型检查，例如(a, b) -> b.compareTo(a)中的a、b被推断为String类型。

边界追问

Lambda表达式能访问所在方法（非静态内部类）的局部变量吗？有什么限制？

边界答案

可以访问，但该变量必须是effectively final（事实上的最终变量）。即变量在初始化后不能被重新赋值。这是为了防止并发修改带来的不确定性。Lambda捕获的是变量的值，而不是引用。如果变量在Lambda外被修改，编译会报错。这个规则确保了线程安全。

记忆锚点

Lambda实现接口，‘箭头函数’省笔墨；变量要当‘常量’用（effectively final），捕获值而非引用。

落地场景

将Collections.sort(names, new Comparator<String>(){...})的匿名内部类实现，简化为Collections.sort(names, (String a, String b) -> b.compareTo(a))，或进一步简化为Collections.sort(names, (a, b) -> b.compareTo(a))。

打开资料

外部资料

掌握@FunctionalInterface注解与函数式接口的规范定义

函数式接口是Lambda表达式存在的基础，它被定义为一个仅包含一个抽象方法的接口。为了明确标识和编译检查，应使用@FunctionalInterface注解。接口中的默认方法（default）和静态方法不影响其函数式接口的特性。JDK 1.8内置了如Comparator、Runnable以及java.util.function包下的大量函数式接口。

诊断题

@FunctionalInterface注解的作用是什么？一个函数式接口能否有多个抽象方法？能否有默认方法和静态方法？请举一个自定义函数式接口的例子。

答案骨架

我能阐述：1) @FunctionalInterface注解用于在编译期检查该接口是否符合函数式接口的规范（有且仅有一个抽象方法），不符合则报错；2) 一个函数式接口只能有一个抽象方法，但可以有多个默认方法（default）和静态方法，因为它们有方法体，不是抽象的；3) 例如，可以定义@FunctionalInterface interface IConverter<F, T> { T convert(F from); }，这个接口可以配合Lambda或方法引用使用。

边界追问

如果一个接口继承了另一个接口，且父接口有两个抽象方法，那么子接口还能被@FunctionalInterface修饰吗？

边界答案

不能。子接口继承了父接口的所有抽象方法，所以它拥有两个抽象方法，不满足“有且仅有一个抽象方法”的条件。只有当子接口通过重写或其他方式（比如在子接口中提供默认实现）将父接口的抽象方法数量减至一个时，才能被视为函数式接口。判断标准是接口最终拥有的抽象方法总数。

记忆锚点

函数式接口，‘独苗’（一个抽象方法）是根；@FunctionalInterface是‘准生证’，default、static是‘自留地’（不影响）。

落地场景

定义@FunctionalInterface interface PersonFactory<P extends Person> { P create(String firstName, String lastName); }，可以使用Lambda PersonFactory<Person> factory = Person::new; 或 (fn, ln) -> new Person(fn, ln) 来创建实例。

打开资料

外部资料

应用方法引用和构造函数引用简化Lambda表达式

方法引用（::操作符）是Lambda表达式的一种进一步简化，用于直接引用已有方法或构造函数。它有四种形式：静态方法引用（ClassName::staticMethod）、任意对象的实例方法引用（ClassName::instanceMethod）、特定对象的实例方法引用（instance::method）和构造函数引用（ClassName::new）。使用前提是方法签名（参数和返回值）与函数式接口的抽象方法签名兼容。

诊断题

方法引用ClassName::instanceMethod和instance::method有什么区别？在什么情况下可以使用构造函数引用ClassName::new？

答案骨架

我能区分：1) ClassName::instanceMethod用于引用任意对象的实例方法，第一个参数是调用该方法的对象，例如String::valueOf可以匹配(Object obj) -> String.valueOf(obj)；2) instance::method用于引用一个特定对象的实例方法，不需要额外参数，例如myObject::toString匹配() -> myObject.toString()；3) 当需要创建一个函数式接口的实例，且其实现是调用某个类的构造函数时，可以使用构造函数引用，例如Supplier<Person> s = Person::new。

边界追问

String::valueOf作为方法引用，可以匹配哪些不同签名的函数式接口？请举出至少两个例子。

边界答案

String::valueOf是静态方法，但有多个重载版本（如valueOf(Object obj), valueOf(char c)）。它可以匹配任何接受一个参数并返回String的函数式接口，具体匹配哪个取决于上下文。例如：1) 可以匹配Function<Object, String>，对应valueOf(Object)；2) 也可以匹配Function<Integer, String>，因为Integer是Object，编译器会进行类型推断。其匹配原则是参数和返回值类型兼容。

记忆锚点

方法引用双冒号::，是Lambda的‘快捷方式’；静态类名、实例名、构造函数名打头，参数省略看签名兼容。

落地场景

将Lambda converter = (from) -> Integer.valueOf(from) 简化为方法引用 converter = Integer::valueOf。将Lambda IConverter<String, String> c = s -> s.toUpperCase() 简化为 IConverter<String, String> c = String::toUpperCase（任意对象的实例方法引用）。

打开资料

外部资料

运用内置函数式接口Function进行链式数据转换

Function<T, R>是JDK 1.8内置的核心函数式接口，代表接受一个参数T并产生结果R的操作。它除了抽象方法apply，还提供了强大的组合方法compose（先执行参数函数再执行自身）和andThen（先执行自身再执行参数函数），允许将多个函数链接起来，形成处理管道。这为函数组合和链式调用提供了基础。

诊断题

Function接口的andThen和compose方法执行顺序有何不同？请描述一个使用Function链式处理字符串，依次进行转Integer、转String、取首字符的实例。

答案骨架

我能解释：1) f.andThen(g)创建的新函数先执行f，再将f的结果作为输入执行g；2) f.compose(g)创建的新函数先执行g，再将g的结果作为输入执行f；3) 例如，可以定义Function<String, Integer> toInt = Integer::valueOf， Function<String, String> backToStr = toInt.andThen(String::valueOf)， Function<String, String> getFirst = backToStr.andThen(s -> String.valueOf(s.charAt(0)))，最终调用getFirst.apply("123")得到“1”。

边界追问

如果使用Function.compose和Function.andThen组合同一个函数两次，效果等价吗？

边界答案

不等价，除非该函数是幂等的（多次执行结果相同且无副作用）。f.compose(f)和f.andThen(f)都应用了f两次，但输入不同：f.compose(f)的完整执行顺序是(input) -> f(input) -> f(f(input))，而f.andThen(f)的顺序是(input) -> f(input) -> f(f(input))。虽然公式一样，但组合顺序会影响可读性，且在使用不同函数组合时差异明显。核心区别在于compose是“先参数后自身”，andThen是“先自身后参数”。

记忆锚点

andThen是“我先练，你接招”；compose是“你先上，我收尾”。链式组合，数据过流水线。

落地场景

Function<String, Integer> toInteger = Integer::valueOf; Function<String, String> backToString = toInteger.andThen(String::valueOf); Function<String, String> afterToStartsWith = backToString.andThen(new Something()::startsWith); // Something类有startsWith方法。

打开资料

外部资料

使用Supplier接口实现惰性计算和对象创建

Supplier<T>是另一个重要的内置函数式接口，它代表结果的提供者。与Function不同，Supplier不接受任何参数，仅通过get()方法返回一个结果T。它常用于惰性计算（延迟执行）、工厂模式以及为某些方法提供默认值。典型用法包括Supplier<Person> personSupplier = Person::new;，每次调用get()都会创建一个新的Person对象。

诊断题

Supplier接口与Function接口的核心区别是什么？Supplier在哪些场景下特别有用？请举例说明如何用Supplier实现惰性初始化。

答案骨架

我能对比：1) 核心区别在于Function<T, R>需要一个输入参数T，而Supplier<T>无输入参数；2) Supplier适用于“无中生有”的场景：延迟创建对象、提供默认值、封装计算密集型操作（仅在需要时执行）；3) 例如，Supplier<ExpensiveObject> lazyObj = () -> new ExpensiveObject();，只有在调用lazyObj.get()时才会真正创建对象，实现了惰性初始化。

边界追问

Supplier<Person> s = Person::new;这行代码创建了Person对象吗？为什么？

边界答案

没有创建Person对象。这行代码只是创建了一个Supplier实例，Person::new是构造函数引用，它定义了get()方法被调用时该如何创建Person对象。new操作只发生在s.get()被调用时。这正是Supplier实现惰性计算的关键：将对象创建的逻辑封装起来，推迟到实际需要的时刻执行。

记忆锚点

Supplier是“供应商”，只管“供货”（get），不收“原料”（无参）。想要才给，延迟生产。

落地场景

Supplier<Person> personSupplier = Person::new;。然后，`Person p1 = personSupplier.get(); // �

打开资料