为何Lambda表达式与方法引用对非final变量采用不同处理方式？

问题背景 #

Lambda表达式中无法引用非final（或等效final）变量，如下代码无法编译：

// doesn't compile
@Test
void methodReferenceTest() {
    String message = "123";
    message = "1234";
    Supplier<Integer> messageLengthSupplier = () -> message.length();
    System.out.print("Message length: ");
    message = "12345";
    System.out.print(messageLengthSupplier.get());
}

但方法引用却允许此类操作，不过方法引用创建后对原变量的重赋值会被忽略：

@Test
void methodReferenceTest() {
    String message = "123";
    message = "1234";
    Supplier<Integer> messageLengthSupplier = message::length;
    System.out.print("Message length: ");
    message = "12345";
    System.out.print(messageLengthSupplier.get()); // prints 4
}

为何Java设计者不对Lambda表达式和方法引用采用统一的处理方式？

核心原因：语义与底层绑定逻辑的本质差异 #

两者的处理规则不同，根源在于它们的语义和底层实现逻辑完全不同：

1. Lambda表达式的变量捕获逻辑 #

Lambda表达式的本质是一段可延迟执行的代码片段，它捕获的是变量本身。要求变量为final/等效final，是为了：

• 避免并发场景下的可见性问题：如果允许变量被修改，Lambda执行时可能读取到未同步的变量值，引发难以排查的并发bug。
• 保证语义清晰：防止开发者误以为后续对变量的修改会被Lambda捕获执行。Lambda在捕获变量时，实际上是保存了变量的当前引用（或值），如果变量可被修改，会导致Lambda的行为变得不可预测。

2. 方法引用的实例绑定逻辑 #

方法引用message::length的本质是绑定了创建那一刻message指向的对象实例的方法句柄，它捕获的是对象实例，而非message这个变量本身：

• 当创建方法引用时，JVM会将其与当时message指向的String对象（"1234"）绑定。
• 后续对message变量的重赋值，只是让变量指向了新的对象，但方法引用已经和原对象绑定，因此调用get()时会返回原对象的长度4。

设计决策的考量：不统一是为了贴合各自语义 #

Java设计者没有统一两者的处理规则，是出于对语义一致性和设计简洁性的考虑：

• Lambda的规则是为了保证其“延迟执行代码块”的语义明确，避免开发者陷入变量修改的陷阱。如果放宽Lambda的变量捕获限制，会大幅增加代码的复杂度和出错概率。
• 方法引用的规则贴合其“指向对象方法”的语义，允许变量非final是合理的——因为方法引用本身不依赖变量的后续变化，只在创建时绑定对象。如果强制要求方法引用的变量必须是final，反而会不必要地限制其使用场景。

另外，方法引用基于Java已有的方法句柄机制实现，而Lambda是全新的语法糖，两者的实现基础不同，强行统一规则会破坏各自的语义完整性，违背Java“简洁、直观”的设计原则。

内容的提问来源于stack exchange，提问作者Cagepi