Java9， Set.of（）和Map.of（）varargs重载[重复]

Question

我正在研究不可变集合的工厂方法。我看到集合了。of（）方法有10个varargs重载（与Map.of（）相同）。我真的不明白为什么有这么多。最后，函数ImmutableCollections。塞恩

在留档里我发现了这个：

虽然这在API中引入了一些混乱，但它避免了由varargs调用引起的数组分配、初始化和垃圾收集开销。

杂乱无章的东西真的值得性能提升吗？如果是，理想情况下，这会为任何N元素创建一个单独的方法吗？




Answer 1

我想这取决于你使用的API的范围。当谈论那些不可变的类时，你谈论的是作为jdk的一部分包含的东西；所以范围很广。

所以你有：

1. 一方面，这些不可变类可能会被应用程序使用，在应用程序中，每一位都会计数（每一纳秒都会浪费在分配/释放上）

如果你实现你自己的东西，我不会那么在意（但是要小心varargs参数），除非你真的需要担心那些额外的比特（和额外的性能等等）。

Answer 2

其中的某些方面可能是未来打样的一种形式。

如果你开发一个API，你需要注意方法签名将如何改变，所以如果我们有

public class API {
  public static final <T> Set<T> of(T... elements) { ... }
}

我们可以说瓦拉格一家足够好。。。除了varargs强制分配一个对象数组，这虽然相当便宜，但实际上会影响性能。例如，请参阅这个微基准，它显示了在切换到varargs表单时，无操作日志记录（即日志级别低于可记录级别）的吞吐量损失为50%。

好的，我们做了一些分析，说最常见的情况是单例，所以我们决定重构。。。

public class API {
  public static final <T> Set<T> of(T first) { ... }
  public static final <T> Set<T> of(T first, T... others) { ... }
}

这不是二进制兼容的它是源兼容的，但不是二进制兼容的为了保持二进制兼容，我们需要保留以前的签名，例如：

public class API {
  public static final <T> Set<T> of(T first) { ... }
  @Deprecated public static final <T> Set<T> of(T... elements) { ... }
  public static final <T> Set<T> of(T first, T... others) { ... }
}

呃...IDE代码完成现在是一团糟...另外，我如何创建一组数组？（可能更相关，如果我使用的是一个列表）API. of（new Object[0]）是含糊不清的...

所以我认为他们所做的是添加足够多的显式参数，以达到额外堆栈大小满足vararg创建成本的程度，这可能是大约10个参数（至少基于Log4J2在将vararg添加到版本2 API时所做的测量）。。。但你这样做是为了基于证据的未来证明。。。

换句话说，我们可以对所有我们没有证据需要专门实现的情况进行欺骗，而只是使用vararg变体：

public class API {
  private static final <T> Set<T> internalOf(T... elements) { ... }
  public static final <T> Set<T> of(T first) { return internalOf(first); }
  public static final <T> Set<T> of(T first, T second) { return internalOf(first, second); }
  ...
  public static final <T> Set<T> of(T t1, T t2, T t3, T t4, T t5, T... rest) { ... }
}

然后，我们可以分析和查看真实世界的使用模式，如果我们看到4 arg表单和基准测试的显著使用率显示有一个合理的性能增益，那么在那一点上，在幕后，我们改变了impl方法，每个人都获得了胜利。。。无需重新编译

Answer 3

无论如何，在调用该方法的那一刻，这可能会改变。例如，它可以创建一个只包含三个元素的集合，4等等。

也不是所有元素都委托给SetN——包含零、一和两个元素的元素具有实际的不可变集合类。Set0，不可变集合。Set1和不可变集合。Set2

或者你可以阅读关于这个的实际问题。。。这里请阅读斯图尔特·马克斯（Stuart Marks）在这个问题上的评论，因为他是这些藏品的创造者。