当我第一次写此博客时，我的目的是向您介绍ThreadLocalRandom类，它是Java 7中新增的用于生成随机数的类。 我在一系列微基准测试中分析了ThreadLocalRandom的性能，以了解其在单线程环境中的性能。

结果相对令人惊讶：尽管代码非常相似，但ThreadLocalRandom速度是Math.random()两倍！ 结果引起了我的兴趣，我决定对此进行进一步的研究。 我已经记录了我的分析过程。 它是对分析步骤，技术和一些JVM诊断工具的示例性介绍，以了解小型代码段的性能差异。 使用上述工具集和技术的一些经验将使您能够为特定的Hotspot目标环境编写更快的Java代码。

好的，这已经足够了，让我们开始吧！ 我的机器是运行Windows XP的普通Intel 386 32位双核。

Math.random()处理Random的静态单例实例，而ThreadLocalRandom -> current() -> nextDouble()处理ThreadLocalRandom的线程本地实例，该实例是Random的子类。 ThreadLocal在对current()方法的每次调用中引入了变量查找的开销。 考虑到我刚才说的话，那么在单个线程中它的速度是Math.random()的两倍，这真的有点令人惊讶吗？ 我没想到会有如此大的差异。

同样，我使用的是Heinz博客之一中介绍的微型基准测试框架。 Heinz开发的框架解决了在现代JVM上对Java程序进行基准测试时遇到的一些挑战。 这些挑战包括：热身，垃圾回收，Java时间API的准确性，测试准确性的验证等等。

这是我可运行的基准测试类：

public class ThreadLocalRandomGenerator implements BenchmarkRunnable {private double r;@Overridepublic void run() {r = r + ThreadLocalRandom.current().nextDouble();}public double getR() {return r;}@Overridepublic Object getResult() {return r;}}public class MathRandomGenerator implements BenchmarkRunnable {private double r;@Overridepublic void run() {r = r + Math.random();}public double getR() {return r;}@Overridepublic Object getResult() {return r;}
}

让我们使用Heinz的框架运行基准测试：

public class FirstBenchmark {private static List<BenchmarkRunnable> benchmarkTargets = Arrays.asList(new MathRandomGenerator(),new ThreadLocalRandomGenerator());public static void main(String[] args) {DecimalFormat df = new DecimalFormat("#.##");for (BenchmarkRunnable runnable : benchmarkTargets) {Average average = new PerformanceHarness().calculatePerf(new PerformanceChecker(1000, runnable), 5);System.out.println("Benchmark target: " + runnable.getClass().getSimpleName());System.out.println("Mean execution count: " + df.format(average.mean()));System.out.println("Standard deviation: " + df.format(average.stddev()));System.out.println("To avoid dead code coptimization: " + runnable.getResult());}}
}

注意：为了确保JVM不会将代码标识为“死代码”，我返回了一个字段变量，并立即打印出基准测试的结果。 这就是为什么我的可运行类实现名为RunnableBenchmark的接口。 我已经运行了三次基准测试。 第一次运行是在默认模式下，启用了内联和JIT优化：

Benchmark target: MathRandomGenerator
Mean execution count: 14773594,4
Standard deviation: 180484,9
To avoid dead code coptimization: 6.4005410634212025E7
Benchmark target: ThreadLocalRandomGenerator
Mean execution count: 29861911,6
Standard deviation: 723934,46
To avoid dead code coptimization: 1.0155096190946539E8

然后再次不进行JIT优化（VM选项-Xint ）：

Benchmark target: MathRandomGenerator
Mean execution count: 963226,2
Standard deviation: 5009,28
To avoid dead code coptimization: 3296912.509302683
Benchmark target: ThreadLocalRandomGenerator
Mean execution count: 1093147,4
Standard deviation: 491,15
To avoid dead code coptimization: 3811259.7334526842

最后一个测试是使用JIT优化，但是使用-XX:MaxInlineSize=0 ，它（几乎）禁用了内联：

Benchmark target: MathRandomGenerator
Mean execution count: 13789245
Standard deviation: 200390,59
To avoid dead code coptimization: 4.802723374491231E7
Benchmark target: ThreadLocalRandomGenerator
Mean execution count: 24009159,8
Standard deviation: 149222,7
To avoid dead code coptimization: 8.378231170741305E7

让我们仔细地解释结果：借助完整的JVM JIT优化， ThreadLocalRanom速度是Math.random()两倍。 关闭JIT优化表明，两者的性能相同（差）。 方法内联似乎使性能相差30％。 其他差异可能归因于其他优化技术 。

JIT编译器可以更有效地调整ThreadLocalRandom原因之一是ThreadLocalRandom.next()的改进实现。

public class Random implements java.io.Serializable {
...protected int next(int bits) {long oldseed, nextseed;AtomicLong seed = this.seed;do {oldseed = seed.get();nextseed = (oldseed * multiplier + addend) & mask;} while (!seed.compareAndSet(oldseed, nextseed));return (int)(nextseed >>> (48 - bits));}
...
}public class ThreadLocalRandom extends Random {
...protected int next(int bits) {rnd = (rnd * multiplier + addend) & mask;return (int) (rnd >>> (48-bits));}
...
}

第一个片段显示Random.next() ，它在Math.random()的基准测试中大量使用。 与ThreadLocalRandom.next()相比，该方法需要更多的指令，尽管这两种方法都做同样的事情。 在Random类中， seed变量将全局共享状态存储到所有线程，并且每次调用next()方法时都会更改。 因此，需要AtomicLong安全地访问和更改对nextDouble()调用中的seed值。 另一方面， ThreadLocalRandom是–很好的–线程局部:-) next()方法不必是线程安全的，可以使用普通的long变量作为种子值。

关于方法内联和ThreadLocalRandom

方法内联是一种非常有效的JIT优化。 在频繁执行的热路径中，热点编译器决定将被调用方法（子方法）的代码内联到调用方方法（父方法）中。 内联具有重要的好处。 它大大降低了方法调用的动态频率，从而节省了执行这些方法调用所需的时间。 但更重要的是，内联会产生更大的代码块，以供优化程序使用。 这就造成了一种情况，大大提高了传统编译器优化的效率，克服了提高Java编程语言性能的主要障碍。”

从Java 7开始，您可以使用诊断JVM选项监视方法内联。 使用' -XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining '运行代码将显示JIT编译器的内联工作。 以下是Math.random()基准测试输出的相关部分：

@ 13   java.util.Random::nextDouble (24 bytes)@ 3   java.util.Random::next (47 bytes)   callee is too large@ 13   java.util.Random::next (47 bytes)   callee is too large

JIT编译器无法内联Random.next()中调用的Random.nextDouble() 。 这是ThreaLocalRandom.next()的内联输出：

@ 8   java.util.Random::nextDouble (24 bytes)@ 3   java.util.concurrent.ThreadLocalRandom::next (31 bytes)@ 13   java.util.concurrent.ThreadLocalRandom::next (31 bytes)

由于next()方法较短（31个字节），因此可以内联。 因为在两个基准测试中都强烈调用next()方法，所以该日志表明方法内联可能是ThreadLocalRandom显着提高执行速度的原因之一。

为了验证并发现更多信息，需要深入研究汇编代码。 使用Java 7 JDK，可以将汇编代码打印到控制台中。 有关如何启用-XX:+PrintAssembly VM选项的信息，请参见此处 。 该选项将打印出JIT优化的代码，这意味着您可以看到JVM实际执行的代码。 我已经将相关的汇编代码复制到下面的链接中。

此处的ThreadLocalRandomGenerator.run（）的汇编代码。
MathRandomGenerator.run（）的汇编代码在此处 。
Math.random（） 在此处调用的Random.next（）的汇编代码。

汇编代码是特定于机器的低级代码， 比起bytecode读起来要复杂得多。 让我们尝试在我的基准测试中验证方法内联对性能的影响，以及：JIT编译器如何对待ThreadLocalRandom和Math.random （）还有其他明显的区别吗？ 在ThreadLocalRandomGenerator.run() ，没有对任何子例程（如Random.nextDouble()或ThreatLocalRandom.next()过程调用。 对ThreadLocal.get()仅有一个虚拟的（因此很昂贵）方法调用（请参阅ThreadLocalRandomGenerator.run()程序集的第35行）。 其他所有代码都内联到ThreadLocalRandomGenerator.run() 。 在的情况下MathRandomGenerator.run()有两个虚拟方法调用到Random.next()见块B4线204页及以后中的汇编代码MathRandomGenerator.run() 这一事实证实了我们的怀疑，即方法内联是导致性能差异的一个重要根本原因。 此外，由于同步的麻烦， Random.next()需要的汇编指令要多得多（并且有些昂贵！），这在执行速度方面也适得其反。

了解invokevirtual指令的开销

那么，为什么（虚拟）方法调用昂贵且方法内联如此有效？ invokevirtual指令的指针不是类实例中具体方法的偏移量。 编译器不知道类实例的内部布局。 相反，它生成对实例方法的符号引用，这些符号引用存储在运行时常量池中。 这些运行时常量池项在运行时解析，以确定实际的方法位置。 这种动态（运行时）绑定需要验证，准备和解决，​​这可能会大大影响性能。 （有关详细信息，请参见JVM规范中的调用方法和链接 ）。

目前为止就这样了。 免责声明：当然，解决性能难题需要了解的主题列表无穷无尽。 除了微基准测试，JIT优化，方法内联，java字节代码，assemby语言等等之外，还有很多东西要理解。 同样，除了虚拟方法调用或昂贵的线程同步指令之外，还有更多导致性能差异的根本原因。 但是，我认为我介绍的主题是此类深入研究的一个很好的开始。 期待批评和愉快的评论！

参考资料：来自JCG合作伙伴 Niklas的“ Java 7：如何编写非常快速的Java代码”。