请解释番石榴代码库中Preconditions.java的热点优化重构？

Question

我正在浏览番石榴代码库和来源有一些解释，如下所示：

所有最近的热点(截至2009年)都非常希望拥有自然代码if (guardExpression) {抛出新的BadException(messageExpression)；} 重构，以便将messageExpression移动到单独的字符串返回方法。如果(guardExpression) {引发新的BadException(badMsg(.))；} 另一种自然重构为无效或异常返回的方法要慢得多。这是一件大事--我们谈论的是微基准中2-8的因素，而不仅仅是10-20%。(这是一个热点优化程序错误，应该修复，但这是一个单独的大型项目)。上面的编码模式在java.util中被大量使用，例如在ArrayList中。JDK中有一个用于测试这一点的RangeCheckMicroBenchmark。但是这个类中的方法想要抛出不同的异常，这取决于args，因此这个模式似乎并不直接适用。但我们可以使用荒谬的诡计，在另一个例外的构造过程中抛出一个例外。热点也没问题。

它适用于哪个jvm？为什么这么慢，我不明白？作为开发者，这对我意味着什么？它是否仍然适用于甲骨文和openjdk的java8 jvms？如何在编写代码时利用这段信息？

Answer 1

它适用于哪个jvm？

HotSpot -Oracle实现

为什么这么慢，我不明白？

这是JVM实现的一个特性。没有什么特别的理由(就JLS/JVMS而言)它应该慢一些，但是在上次有人描述它的时候，它是。您找到的RangeCheckMicroBenchmark类包含更多的细节和示例。

作为开发者，这对我意味着什么？

没什么。除非您正在实现像Preconditions这样的类--这类的数百万次使用都需要尽可能接近零开销--否则您没有理由担心这个细节。这就是为什么它是一个代码注释，而不是Javadoc注释。

它是否仍然适用于甲骨文和openjdk的java8 jvms？

可能是的。该注释没有链接到特定的HotSpot错误，但是您可以搜索JDK邮件列表中提到的基准代码，并找到相关的bug。

如果Preconditions的行为发生变化，很可能会更新JVM。

如何在编写代码时利用这段信息？

真的没有必要这样做。如果你最后写了番石榴2.0，你会(希望)运行你自己的基准测试，并会发现瓶颈值得这样解决。试图利用微优化而不对自己的代码进行严格的基准测试，可能弊大于利。