在 Java 8 引入函数式编程特性后，Supplier 接口成为了一个常用的函数式接口，它代表一个提供值的函数。在某些场景下，我们需要将当前对象实例 (this) 传递给 Supplier，例如在使用 java.util.concurrent.CompletableFuture 的 completeAsync 方法时。本文将探讨如何以最高效的方式实现这一目标，并分析不同方法的优缺点。
Lambda 表达式 vs. 方法引用
假设我们有如下类 Thing：
import java.util.concurrent.CompletableFuture;
class Thing<T> {
final T value;
final CompletableFuture<T> future;
Thing(T value) {
this.value = value;
this.future = new CompletableFuture<>();
}
Thing<T> self() {
return this;
}
void reject() {
future.cancel(false);
}
void complete() {
// 使用 Lambda 表达式
future.completeAsync(() -> this);
// 使用方法引用
future.completeAsync(this::self);
}
CompletableFuture<T> getFuture() {
return future;
}
}在 complete 方法中，我们使用了两种方式将 this 传递给 completeAsync 方法：
- Lambda 表达式： () -> this
- 方法引用： this::self
那么，这两种方式在性能上有什么差异呢？
立即学习“Java免费学习笔记（深入）”；
性能考量
从理论上讲，方法引用通常比 Lambda 表达式更高效。这是因为 Lambda 表达式在编译时会生成一个匿名类，而方法引用则直接指向已存在的方法。这意味着使用 Lambda 表达式会产生额外的对象分配和类加载开销。
然而，在实际应用中，这种差异通常可以忽略不计，尤其是在现代 JVM 的优化下。JVM 可能会内联 Lambda 表达式，从而消除额外的对象分配。
因此，在选择使用 Lambda 表达式还是方法引用时，更应该考虑代码的可读性和简洁性。
代码可读性
在 Thing 类的例子中，this::self 比 () -> this 更具可读性，因为它明确地表达了“获取当前对象实例”的意图。 self() 方法的存在使得代码的意图更加清晰。 如果没有 self() 方法，仅仅为了传递 this 而创建一个，那么 Lambda 表达式 () -> this 在这种情况下可能更简洁一些。
注意事项
- 避免过度优化： 在性能瓶颈出现之前，不要过度关注 Lambda 表达式和方法引用之间的细微差异。优先考虑代码的可读性和可维护性。
- 上下文相关： 在不同的上下文中，Lambda 表达式和方法引用的适用性可能会有所不同。根据具体情况选择最合适的方案。
- 关注 JVM 优化： 现代 JVM 能够对 Lambda 表达式进行优化，从而减少性能开销。
总结
将当前对象实例 (this) 传递给 Supplier 可以通过 Lambda 表达式或方法引用实现。方法引用通常更高效，但实际性能差异可能很小。在选择时，应优先考虑代码的可读性和简洁性，并根据具体情况选择最合适的方案。在确认性能瓶颈之前，避免过度优化。
