每次将 lambda () => 1 作为参数传递时，是否会在运行时创建对象？

如何解决每次将 lambda () => 1 作为参数传递时，是否会在运行时创建对象？

我的理解是，所有非捕获 lambda 都不应该要求在使用站点创建对象，因为可以将对象创建为静态字段并重复使用。原则上，对于构成类方法调用的 lambdas 也是如此——只有该字段是非静态的。我从未真正尝试过深入挖掘它；现在我正在查看字节码，在封闭类中没有看到字节码，也不知道在哪里看？我看到 lambda 工厂与 Java 中的不同，所以这应该有一个明确的答案 - 至少对于给定的 Scala 版本。

我的动机很简单：分析非常耗时。将方法值（或一般来说，只捕获封闭对象状态的 lambdas）作为私有类字段引入，比内联编写它们更不干净，工作量更大，而且通常不是好的代码。但是当编写已知（很有可能）是热点的区域时，这是一个非常简单的优化，可以立即执行，而不会对程序员的时间产生任何实际影响。如果无论如何都没有创建新对象，这没有任何意义。

举个例子：

def alias(x :X) = aliases.getorElse(x,x)

def alias2(x :X) = aliases.getorElse(x,null) match {
    case null => x
    case a => a
}

第一个 lambda (a Function0) 必须是一个新对象，因为它捕获方法参数 x，而第二个返回一个常量 (null)，因此实际上并没有不得不。它也没有私有类字段那么混乱 (IMO)，它会污染命名空间，但我希望能够确定 - 或者有一种方法可以轻松确认我的期望。

解决方法

以下证明至少在某些时候，答案是“否”：

scala 2.13.4> def foo = () => 1
def foo: () => Int

scala 2.13.4> foo eq foo
val res5: Boolean = true

,

看这段代码产生的字节码：

import scala.collection.immutable.ListMap

object ByName {
  def aliases = ListMap("Ein" -> "One","Zwei" -> "Two","Drei" -> "Three")

  val default = "NaN"

  def alias(x: String) = aliases.getOrElse(x,x)

  def alias2(x: String) = aliases.getOrElse(x,null) match {
      case null => x
      case a => a
  }
  def alias3(x: String) = aliases.getOrElse(x,default)
}

编译器为按名称参数生成静态方法。它们看起来像这样：

  public static final java.lang.String $anonfun$alias$1(java.lang.String);
    Code:
       0: aload_0
       1: areturn

  public static final scala.runtime.Null$ $anonfun$alias2$1();
    Code:
       0: aconst_null
       1: areturn

  public static final java.lang.String $anonfun$alias3$1();
    Code:
       0: getstatic     #26                 // Field MODULE$:LByName$;
       3: invokevirtual #138                // Method default:()Ljava/lang/String;
       6: areturn

最简单的方法是编译器生成实现 Function0 接口的匿名类。但是，这会导致字节码膨胀。相反，编译器通过 invokedynamic 指令将创建这些匿名内部类推迟到运行时。

我不知道 Scala 究竟如何使用这些 invokedynamic 指令。他们可能会以某种方式缓存生成的 Function0 对象，但我的猜测是 invokedynamic 调用已经过充分优化，每次生成一个新对象会更快。分配寿命较短的对象很便宜，而且成本通常被高估。如果这意味着缓存未命中，重用现有对象甚至可能比创建新对象慢。

我还想指出，这是一个实现细节，可能随时更改。 Scala 编译器开发人员和 JVM 开发人员知道他们在做什么，因此您最好相信他们的实现能够很好​​地平衡性能。