lambda捕获this_非捕获Lambda的实例

lambda捕获this

大约一个月前，我在Java 8的lambda表达式框架下总结了Brian Goetz的观点。目前，我正在研究有关默认方法的文章，令我惊讶的是，我又回到了Java处理lambda表达式的方式。这两个功能的交集可能会产生微妙但令人惊讶的效果，我想讨论一下。

总览

为了使这一点更有趣，我将以一个示例开头，该示例将以我的个人WTF达到顶峰？时刻。完整的示例可以在专用的GitHub项目中找到。

然后，我们将看到有关此意外行为的解释，并最终得出一些结论以防止错误。

例

这里有个例子……它不是那么简单或抽象，因为我希望它显示这种情况的相关性。但是从某种意义上说，这仍然是一个示例，它仅暗示实际上可能有用的代码。

功能界面

假设对于在构建过程中已经存在结果的场景，我们需要对Future接口进行特殊化。

我们决定通过创建一个接口ImmediateFuture来实现此目的，该接口get()使用默认方法实现除get()之外的所有功能。这导致功能界面。

您可以在此处查看源代码。

一个工厂

接下来，我们实现FutureFactory 。它可能会创建各种期货，但肯定会创建我们的新子类型。它是这样的：

未来工厂

/*** Creates a new future with the default result.*/
public static Future<Integer> createWithDefaultResult() {ImmediateFuture<Integer> immediateFuture = () -> 0;return immediateFuture;
}/*** Creates a new future with the specified result.*/
public static Future<Integer> createWithResult(Integer result) {ImmediateFuture<Integer> immediateFuture = () -> result;return immediateFuture;
}

创造未来

最后，我们使用工厂创建一些期货并将其收集在一组中：

创建实例

public static void main(String[] args) {Set<Future<?>> futures = new HashSet<>();futures.add(FutureFactory.createWithDefaultResult());futures.add(FutureFactory.createWithDefaultResult());futures.add(FutureFactory.createWithResult(42));futures.add(FutureFactory.createWithResult(63));System.out.println(futures.size());
}

WTF ？！

运行程序。控制台会说...

4？不。 3。

WTF ？！

Lambda表达式的评估

那么这是怎么回事？那么，与有关lambda表达式的评估一些背景知识，这其实并不奇怪。如果您不太熟悉Java的实现方式，那么现在是赶上Java的好时机。做到这一点的一种方法是观看Brian Goetz的演讲“ Java中的Lambdas：深入了解”或阅读我的摘要。

Lambda表达式的实例

理解这种行为的关键在于，事实是JRE不保证如何将lambda表达式转换为相应接口的实例。让我们看一下Java语言规范对此事的看法：

15.27.4。 Lambda表达式的运行时评估

[…]

分配并初始化具有以下属性的类的新实例，或者引用具有以下属性的类的现有实例。

[…类的属性–这里不足为奇…]

这些规则旨在通过以下方式为Java编程语言的实现提供灵活性：

不必在每次评估中分配一个新对象。

由不同的lambda表达式产生的对象不必属于不同的类（例如，如果主体相同）。

评估产生的每个对象不必属于同一类（例如，可以内联捕获的局部变量）。

如果“现有实例”可用，则不需要在先前的lambda评估中创建它（例如，可能在封闭类的初始化期间分配了它）。

[…]

JLS，Java SE 8版，§15.27.4

在其他优化中，这显然使JRE可以返回相同的实例，以重复评估lambda表达式。

非捕获Lambda表达式的实例

请注意，在上面的示例中，表达式不捕获任何变量。因此，它永远不会因评估而改变。而且由于lambda并非设计为具有状态，因此不同的评估在其生命周期中也无法“分散”。因此，一般而言，没有充分的理由来创建多个不捕获的lambda实例，因为它们在整个生命周期中都完全相同。这样可以使优化始终返回相同的实例。

（将其与捕获某些变量的lambda表达式进行对比。对此表达式的直接评估是创建一个将捕获的变量作为字段的类。每个评估都必须创建一个新实例，将捕获的变量存储在其字段中这些情况显然并不普遍。）

这就是上面代码中发生的事情。 () -> 0是一个不捕获的lambda表达式，因此每个评估都返回相同的实例。因此，对createWithDefaultResult()每次调用都是如此。

但是，请记住，这仅适用于当前安装在我的计算机上的JRE版本（用于Win 64的Oracle 1.8.0_25-b18）。您的可以有所不同，下一个gal也可以如此等等。

得到教训

因此，我们了解了为什么会这样。尽管这很有意义，但我仍然会说这种行为并不明显，因此并不是每个开发人员都期望的。这是漏洞的滋生地，因此让我们尝试分析情况并从中学习一些东西。

使用默认方法进行子类型化

可以说，意外行为的根本原因是如何完善Future的决定。为此，我们扩展了另一个接口，并使用默认方法实现了部分功能。仅剩一个未实现的方法， ImmediateFuture成为了一个启用lambda表达式的功能接口。

另外， ImmediateFuture可以是抽象类。这样可以防止工厂意外返回相同的实例，因为它不能使用lambda表达式。

关于抽象类和默认方法的讨论不容易解决，因此在这里我不尝试这样做。但是，我很快将发布有关默认方法的文章，并且我打算再讲一遍。可以说，在做出决定时应考虑此处提出的案例。

工厂中的Lambda

由于lambda的引用相等性不可预测，因此工厂方法应仔细考虑使用它们来创建实例。除非方法的协定明确允许不同的调用返回相同的实例，否则应完全避免使用它们。

我建议在此禁令中包括捕获lambda。（对我而言）一点也不清楚，在什么情况下可以在将来的JRE版本中重用同一实例。一种可能的情况是，JIT发现紧密的循环创建了总是（或至少经常）返回同一实例的供应商。通过用于不捕获lambda的逻辑，重用同一供应商实例将是有效的优化。

匿名类与Lambda表达式

注意匿名类和lambda表达式的不同语义。前者保证创建新实例，而后者则不能。为了继续该示例，以下createWithDefaultResult()将导致futures –大小为4的集合：

匿名类的替代实现

public static Future<Integer> createWithDefaultResult() {ImmediateFuture<Integer> immediateFuture = new ImmediateFuture<Integer>() {@Overridepublic Integer get() throws InterruptedException, ExecutionException {return 0;}};return immediateFuture;
}

这尤其令人不安，因为许多IDE允许从匿名接口实现到lambda表达式的自动转换，反之亦然。由于两者之间存在细微的差异，这种看似纯粹的句法转换会带来细微的行为变化。（我最初并不了解。）

万一您遇到了这种情况，并选择使用匿名类，请确保以明显方式记录您的决定！不幸的是，似乎没有办法阻止Eclipse对其进行任何转换（例如，如果将转换作为保存操作启用），这也会删除匿名类中的所有注释。

最终的替代方案似乎是一个（静态）嵌套类。我知道没有哪个IDE敢将其转换为lambda表达式，因此这是最安全的方法。尽管如此，仍需要对其进行文档记录，以防止下一个Java-8迷（确实像您一样）出现并加紧您的仔细考虑。

功能接口标识

当您依赖功能接口的标识时要小心。始终考虑是否有可能，无论您在何处获得这些实例，都可能反复将您交给同一个实例。

但这当然是模糊的，几乎没有什么具体的结果。首先，所有其他接口都可以简化为功能接口。这实际上就是我选择Future的原因-我想举一个不会立即尖叫疯狂的LAMBDA狗屎的例子！其次，这会使您很快变得偏执。

因此，请不要过分考虑-记住这一点。

保证行为

最后但并非最不重要的一点（这始终是正确的，但值得在此重复）：

不要依靠无证的行为！

JLS不保证每个lambda评估都返回一个新实例（如上面的代码所示）。但是它不能保证观察到的行为，即非捕获的lambda总是由同一实例表示。因此，不要编写依赖于两者的代码。

不过，我必须承认，这是一个艰难的过程。认真地说，谁在使用某些功能之前先看过它们的JLS？我当然不会。

反射

我们已经看到Java不能保证所评估的lambda表达式的身份。尽管这是一个有效的优化，但它可能会产生令人惊讶的效果。为了防止这种情况引入细微的错误，我们导出了以下准则：

使用默认方法部分实现接口时要小心。
不要在工厂方法中使用lambda表达式。
当身份很重要时，请使用匿名类或更好的内部类。
依赖功能接口的标识时要小心。
最后， 不要依赖未记录的行为！

翻译自: https://www.javacodegeeks.com/2015/01/instances-of-non-capturing-lambdas.html

lambda捕获this