在执行顺序（几乎）不变的情况下，分配变量如何会导致性能严重下降？

Question

在使用多线程时，我可以观察到一些与 AtomicLong（以及使用它的类，例如 java.util.Random）相关的一些意外但严重的性能问题，目前我还没有任何解释。但是，我创建了一个简约的示例，它基本上由两个类组成：类“Container”，它保留对易失性变量的引用，以及类“DemoThread”，它在线程执行期间对“Container”的实例进行操作。请注意，对“Container”和 volatile long 的引用是私有的，并且永远不会在线程之间共享（我知道这里不需要使用 volatile，它只是用于演示目的） - 因此，“DemoThread”的多个实例应该完美运行在多处理器机器上并行，但由于某种原因，它们没有（完整的示例位于本文的底部）。

private static class Container  {

    private volatile long value;

    public long getValue() {
        return value;
    }

    public final void set(long newValue) {
        value = newValue;
    }
}

private static class DemoThread extends Thread {

    private Container variable;

    public void prepare() {
        this.variable = new Container();
    }

    public void run() {
        for(int j = 0; j < 10000000; j++) {
            variable.set(variable.getValue() + System.nanoTime());
        }
    }
}

在我的测试过程中，我重复创建了 4 个 DemoThread，然后启动并连接它们。每个循环中唯一的区别是“prepare()”被调用的时间（这显然是线程运行所必需的，否则会导致 NullPointerException）：

DemoThread[] threads = new DemoThread[numberOfThreads];
    for(int j = 0; j < 100; j++) {
        boolean prepareAfterConstructor = j % 2 == 0;
        for(int i = 0; i < threads.length; i++) {
            threads[i] = new DemoThread();
            if(prepareAfterConstructor) threads[i].prepare();
        }

        for(int i = 0; i < threads.length; i++) {
            if(!prepareAfterConstructor) threads[i].prepare();
            threads[i].start();
        }
        joinThreads(threads);
    }

出于某种原因，如果在之前立即执行prepare()启动线程，需要两倍的时间才能完成，即使没有“易失性”关键字，性能差异也很大，至少在我测试代码的两台机器和操作系统上是这样。以下是简短摘要：

---

Mac OS 摘要：

Java 版本：1.6.0_24
Java 类版本：50.0
VM 供应商：Sun Microsystems Inc.
虚拟机版本：19.1-b02-334
虚拟机名称：Java HotSpot(TM) 64 位服务器虚拟机
操作系统名称：Mac OS X
操作系统架构：x86_64
操作系统版本：10.6.5
处理器/内核：8 个

，带有 volatile 关键字：
最终结果：
31979 女士当实例化后调用prepare()时。
96482 女士当在执行之前调用prepare()时。

没有 volatile 关键字：
最终结果：
26009 女士当实例化后调用prepare()时。
35196 女士当在执行之前调用prepare()时。

---

Windows 摘要：

Java 版本：1.6.0_24
Java 类版本：50.0
VM 供应商：Sun Microsystems Inc.
虚拟机版本：19.1-b02
虚拟机名称：Java HotSpot(TM) 64 位服务器虚拟机
操作系统名称：Windows 7
操作系统架构：amd64
操作系统版本：6.1
处理器/内核：4 个

，带有 volatile 关键字：
最终结果：
18120 女士当实例化后调用prepare()时。
36089 女士当在执行之前调用prepare()时。

没有 volatile 关键字：
最终结果：
10115 女士当实例化后调用prepare()时。
10039 女士当在执行之前调用prepare()时。

---

Linux 摘要：

Java 版本：1.6.0_20
Java 类版本：50.0
VM 供应商：Sun Microsystems Inc.
虚拟机版本：19.0-b09
虚拟机名称：OpenJDK 64 位服务器虚拟机
操作系统名称：Linux
操作系统架构：amd64
操作系统版本：2.6.32-28-generic
处理器/内核：4 个

，带有 volatile 关键字：
最终结果：
45848 女士当实例化后调用prepare()时。
110754 女士当在执行之前调用prepare()时。

没有 volatile 关键字：
最终结果：
37862 女士当实例化后调用prepare()时。
39357 女士当在执行之前调用prepare()时。

---

Mac OS 详细信息（易失性）：

测试 1、4 个线程，在创建循环中设置变量
线程 2 在 653 毫秒后完成。
线程 3 在 653 毫秒后完成。
线程 4 在 653 毫秒后完成。
线程 5 在 653 毫秒后完成。
总时间：654 毫秒。

测试 2、4 个线程，在启动循环中设置变量
线程 7 在 1588 毫秒后完成。
线程 6 在 1589 毫秒后完成。
线程 8 在 1593 毫秒后完成。
线程 9 在 1593 毫秒后完成。
总时间：1594 毫秒。

测试 3、4 个线程，在创建循环中设置变量
Thread-10 在 648 毫秒后完成。
线程 12 在 648 毫秒后完成。
线程 13 在 648 毫秒后完成。
线程 11 在 648 毫秒后完成。
总时间：648 毫秒。

测试 4、4 个线程，在启动循环中设置变量
Thread-17 在 1353 毫秒后完成。
Thread-16 在 1957 毫秒后完成。
Thread-14 在 2170 毫秒后完成。
Thread-15 在 2169 毫秒后完成。
总时间：2172 毫秒。

（依此类推，有时“慢”循环中的一两个线程会按预期完成，但大多数时候不会）。

给定的示例从理论上看是没有用的，并且这里不需要“易失性” - 但是，如果您使用“java.util.Random”实例而不是“容器”类并调用，例如，多次使用nextInt()，会发生相同的效果：如果在线程的构造函数中创建对象，线程将执行得很快，但如果在run()方法中创建对象，则执行速度会很慢。我相信 Mac OS 上的 Java 随机减速 中描述的性能问题超过一年前与这种效果有关，但我不知道为什么会这样 - 除此之外，我确信它不应该是这样的，因为这意味着在其中创建一个新对象总是很危险的线程的运行方法，除非您知道对象图中不会涉及任何易失性变量。分析没有帮助，因为在这种情况下问题消失了（与 中的观察结果相同） Mac OS 上的 Java 随机变慢（续）），并且它也不会发生在单核 PC 上 - 所以我猜这是一个线程同步问题......但是，奇怪的事情实际上没有什么需要同步的，因为所有变量都是线程本地的。

真的很期待任何提示 - 如果您想确认或伪造问题，请参阅下面的测试用例。

谢谢，

斯蒂芬

public class UnexpectedPerformanceIssue {

private static class Container  {

    // Remove the volatile keyword, and the problem disappears (on windows)
    // or gets smaller (on mac os)
    private volatile long value;

    public long getValue() {
        return value;
    }

    public final void set(long newValue) {
        value = newValue;
    }
}

private static class DemoThread extends Thread {

    private Container variable;

    public void prepare() {
        this.variable = new Container();
    }

    @Override
    public void run() {
        long start = System.nanoTime();
        for(int j = 0; j < 10000000; j++) {
            variable.set(variable.getValue() + System.nanoTime());
        }
        long end = System.nanoTime();
        System.out.println(this.getName() + " completed after "
                +  ((end - start)/1000000) + " ms.");
    }
}

public static void main(String[] args) {
    System.out.println("Java Version: " + System.getProperty("java.version"));
    System.out.println("Java Class Version: " + System.getProperty("java.class.version"));

    System.out.println("VM Vendor: " + System.getProperty("java.vm.specification.vendor"));
    System.out.println("VM Version: " + System.getProperty("java.vm.version"));
    System.out.println("VM Name: " + System.getProperty("java.vm.name"));

    System.out.println("OS Name: " + System.getProperty("os.name"));
    System.out.println("OS Arch: " + System.getProperty("os.arch"));
    System.out.println("OS Version: " + System.getProperty("os.version"));
    System.out.println("Processors/Cores: " + Runtime.getRuntime().availableProcessors());

    System.out.println();
    int numberOfThreads = 4;

    System.out.println("\nReference Test (single thread):");
    DemoThread t = new DemoThread();
    t.prepare();
    t.run();

    DemoThread[] threads = new DemoThread[numberOfThreads];
    long createTime = 0, startTime = 0;
    for(int j = 0; j < 100; j++) {
        boolean prepareAfterConstructor = j % 2 == 0;
        long overallStart = System.nanoTime();
        if(prepareAfterConstructor) {
            System.out.println("\nTest " + (j+1) + ", " + numberOfThreads + " threads, setting variable in creation loop");             
        } else {
            System.out.println("\nTest " + (j+1) + ", " + numberOfThreads + " threads, setting variable in start loop");
        }

        for(int i = 0; i < threads.length; i++) {
            threads[i] = new DemoThread();
            // Either call DemoThread.prepare() here (in odd loops)...
            if(prepareAfterConstructor) threads[i].prepare();
        }

        for(int i = 0; i < threads.length; i++) {
            // or here (in even loops). Should make no difference, but does!
            if(!prepareAfterConstructor) threads[i].prepare();
            threads[i].start();
        }
        joinThreads(threads);
        long overallEnd = System.nanoTime();
        long overallTime = (overallEnd - overallStart);
        if(prepareAfterConstructor) {
            createTime += overallTime;
        } else {
            startTime += overallTime;
        }
        System.out.println("Overall time: " + (overallTime)/1000000 + " ms.");
    }
    System.out.println("Final results:");
    System.out.println(createTime/1000000 + " ms. when prepare() was called after instantiation.");
    System.out.println(startTime/1000000 + " ms. when prepare() was called before execution.");
}

private static void joinThreads(Thread[] threads) {
    for(int i = 0; i < threads.length; i++) {
        try {
            threads[i].join();
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
}

}

Answer 1

好吧，你正在写入一个易失性变量，所以我怀疑这会强制内存屏障 - 撤消一些原本可以实现的优化。 JVM 不知道该特定字段不会在另一个线程上被观察到。

编辑：如上所述，基准测试本身存在问题，例如在计时器运行时进行打印。此外，在开始计时之前“预热”JIT 通常是个好主意 - 否则您测量的时间在正常的长时间运行过程中并不重要。

Answer 2

我不是 Java 内部的专家，但我读了你的问题并发现它很有趣。如果我不得不猜测，我想你发现了什么：

1. 与 volitale 属性的实例化没有任何关系。但是，从您的数据来看，实例化属性的位置会影响读/写它的成本。

2. 与在运行时查找 volitale 属性的引用有关。也就是说，我有兴趣了解延迟如何随着更多循环更频繁的线程而增加。是对 volitale 属性的调用次数导致了延迟，还是添加本身，或者是新值的写入。

我不得不猜测：可能有一个 JVM 优化尝试快速实例化属性，然后，如果有时间，更改内存中的属性，以便更容易读/写它。也许有一个 (1) 快速创建 volitale 属性的读/写队列，以及一个 (2) 难以创建但快速调用的队列，并且 JVM 从 (1) 开始，然后更改 volitale 属性至（2）。

也许如果您在调用 run() 方法之前准备 prepare()，则 JVM 没有足够的空闲周期来优化 (1) 到 (2)。

测试这个答案的方法是：

prepare()、sleep()、run()，看看是否得到相同的延迟。如果睡眠是导致优化发生的唯一因素，那么这可能意味着 JVM 需要循环来优化 volitale 属性

，或者（风险更大一些）...

prepare() 和 run() 线程，稍后在循环中间，暂停（）或睡眠（）或以某种方式停止对该属性的访问，以便 JVM 可以尝试将其移动到（2）。

我很想看看你能发现什么。有趣的问题。

Answer 3

嗯，我看到的最大区别在于对象的分配顺序。在构造函数之后准备时，容器分配与线程分配交错。在执行前准备时，首先分配所有线程，然后分配所有容器。

我不太了解多处理器环境中的内存问题，但如果我不得不猜测，也许在第二种情况下，容器分配更有可能分配在同一内存页中，并且处理器可能会变慢由于同一内存页的争用而导致停机？

[编辑] 按照这个思路，我很想看看如果您不尝试写回变量，而只在线程的 run 方法中读取变量，会发生什么。我希望时间差异会消失。

[edit2]参见irreputable的回答；他比我解释得好得多

Answer 4

很可能两个易失性变量 a 和 b 彼此太接近，它们落在同一个缓存行中；虽然CPU A 仅读取/写入变量a，CPU B 仅读取/写入变量b，但它们是仍然通过同一高速缓存线相互耦合。此类问题称为错误共享。

在您的示例中，我们有两种分配方案：

new Thread                               new Thread
new Container               vs           new Thread
new Thread                               ....
new Container                            new Container
....                                     new Container

在第一个方案中，两个 volatile 变量不太可能彼此接近。在第二种方案中，几乎可以肯定是这种情况。

CPU 缓存不能处理单个字；相反，它们处理缓存行。高速缓存行是一块连续的内存块，例如 64 个相邻字节。通常这很好 - 如果 CPU 访问一个单元，它很可能也会访问相邻的单元。除了您的示例之外，该假设不仅无效，而且是有害的。

假设a和b落在同一个缓存行L中。当CPU A 更新a 时，它会通知其他CPU L 已脏。由于 B 也缓存 L，因为它正在 b 上工作，所以 B 必须删除其缓存的 L。所以下次B需要读取b时，必须重新加载L，这是昂贵的。

如果 B 必须访问主内存来重新加载，那么成本极高，通常会慢 100 倍。

幸运的是，A 和 B 可以直接就新值进行通信，而无需通过主内存。然而，这需要额外的时间。

为了验证这个理论，你可以在Container中额外填充128字节，这样两个Container的两个易失性变量就不会落在同一个缓存行中；那么您应该观察到这两个方案的执行时间大约相同。

经验教训：CPU 通常假设相邻变量是相关的。如果我们想要自变量，我们最好将它们放置得彼此远离。