观察以下用Java编写的程序（完整的可运行版本如下，但程序的重要部分在下面的代码片段中）：
import java.util.ArrayList;
/** A not easy to explain benchmark.
*/
class MultiVolatileJavaExperiment {
public static void main(String[] args) {
(new MultiVolatileJavaExperiment()).mainMethod(args);
}
int size = Integer.parseInt(System.getProperty("size"));
int par = Integer.parseInt(System.getProperty("par"));
public void mainMethod(String[] args) {
int times = 0;
if (args.length == 0) times = 1;
else times = Integer.parseInt(args[0]);
ArrayList < Long > measurements = new ArrayList < Long > ();
for (int i = 0; i < times; i++) {
long start = System.currentTimeMillis();
run();
long end = System.currentTimeMillis();
long time = (end - start);
System.out.println(i + ") Running time: " + time + " ms");
measurements.add(time);
}
System.out.println(">>>");
System.out.println(">>> All running times: " + measurements);
System.out.println(">>>");
}
public void run() {
int sz = size / par;
ArrayList < Thread > threads = new ArrayList < Thread > ();
for (int i = 0; i < par; i++) {
threads.add(new Reader(sz));
threads.get(i).start();
}
for (int i = 0; i < par; i++) {
try {
threads.get(i).join();
} catch (Exception e) {}
}
}
final class Foo {
int x = 0;
}
final class Reader extends Thread {
volatile Foo vfoo = new Foo();
Foo bar = null;
int sz;
public Reader(int _sz) {
sz = _sz;
}
public void run() {
int i = 0;
while (i < sz) {
vfoo.x = 1;
// with the following line commented
// the scalability is almost linear
bar = vfoo; // <- makes benchmark 2x slower for 2 processors - why?
i++;
}
}
}
}
解释：该程序实际上非常简单。它从系统属性加载整数size和par（传递给带有-D标志的jvm） - 这些是输入长度和稍后要使用的线程数。然后它解析第一个命令行参数，该参数说明重复程序需要多少时间（我们希望确保JIT已完成其工作并具有更可靠的测量值）。
每次重复都会调用run方法。此方法只是启动par个线程，每个线程将执行size / par次迭代的循环。线程主体在Reader类中定义。循环的每次重复都会读取易失性成员vfoo并将1分配给其公共字段。之后，再次阅读vfoo并将其分配到非易失性字段bar。
注意程序执行循环体的大部分时间，因此线程中的run是此基准测试的焦点：
final class Reader extends Thread {
volatile Foo vfoo = new Foo();
Foo bar = null;
int sz;
public Reader(int _sz) {
sz = _sz;
}
public void run() {
int i = 0;
while (i < sz) {
vfoo.x = 1;
// with the following line commented
// the scalability is almost linear
bar = vfoo; // <- makes benchmark 2x slower for 2 processors - why?
i++;
}
}
}
观察：在
上运行java -Xmx512m -Xms512m -server -Dsize=500000000 -Dpar=1 MultiVolatileJavaExperiment 10
Ubuntu Server 10.04.3 LTS
8 core Intel(R) Xeon(R) CPU X5355 @2.66GHz
~20GB ram
java version "1.6.0_26"
Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode)
我得到以下时间：
>>> All running times: [821, 750, 1011, 750, 758, 755, 1219, 751, 751, 1012]
现在，设置-Dpar=2，我得到：
>>> All running times: [1618, 380, 1476, 1245, 1390, 1391, 1445, 1393, 1511, 1508]
显然，由于某些原因，这不会缩放 - 我原本预计第二个输出的速度会快两倍（尽管它似乎是早期迭代中的一个 - 380ms）。
有趣的是，注释掉行bar = vfoo（甚至不应该是易失性写入）会产生以下-Dpar设置为1,2,4,8的时间。
>>> All running times: [762, 563, 563, 563, 563, 563, 570, 566, 563, 563]
>>> All running times: [387, 287, 285, 284, 283, 281, 282, 282, 281, 282]
>>> All running times: [204, 146, 143, 142, 141, 141, 141, 141, 141, 141]
>>> All running times: [120, 78, 74, 74, 81, 75, 73, 73, 72, 71]
它完美地扩展。
分析：首先，这里没有垃圾收集周期（我已经添加了-verbose:gc来检查）。
我在iMac上得到了类似的结果。
每个线程都写入自己的字段，属于不同线程的不同Foo对象实例似乎不会在同一个缓存行中结束 - 将更多成员添加到Foo以增加其尺寸不会改变测量值。每个线程对象实例都有足够的字段来填充L1缓存行。所以这可能不是内存问题。
我的下一个想法是JIT可能做了一些奇怪的事情，因为早期的迭代通常做按照预期在未注释版本中进行扩展，所以我通过打印程序集来检查它（见this post on how to do that）。
java -Xmx512m -Xms512m -server -XX:CompileCommand=print,*Reader.run MultiVolatileJavaExperiment -Dsize=500000000 -Dpar=1 10
我为run中的Jitted方法Reader获得了2个版本的这两个输出。评论（适当扩展）版本：
[Verified Entry Point]
0xf36c9fac: mov %eax,-0x3000(%esp)
0xf36c9fb3: push %ebp
0xf36c9fb4: sub $0x8,%esp
0xf36c9fba: mov 0x68(%ecx),%ebx
0xf36c9fbd: test %ebx,%ebx
0xf36c9fbf: jle 0xf36c9fec
0xf36c9fc1: xor %ebx,%ebx
0xf36c9fc3: nopw 0x0(%eax,%eax,1)
0xf36c9fcc: xchg %ax,%ax
0xf36c9fd0: mov 0x6c(%ecx),%ebp
0xf36c9fd3: test %ebp,%ebp
0xf36c9fd5: je 0xf36c9ff7
0xf36c9fd7: movl $0x1,0x8(%ebp)
---------------------------------------------
0xf36c9fde: mov 0x68(%ecx),%ebp
0xf36c9fe1: inc %ebx ; OopMap{ecx=Oop off=66}
;*goto
; - org.scalapool.bench.MultiVolatileJavaExperiment$Reader::run@21 (line 83)
---------------------------------------------
0xf36c9fe2: test %edi,0xf7725000 ; {poll}
0xf36c9fe8: cmp %ebp,%ebx
0xf36c9fea: jl 0xf36c9fd0
0xf36c9fec: add $0x8,%esp
0xf36c9fef: pop %ebp
0xf36c9ff0: test %eax,0xf7725000 ; {poll_return}
0xf36c9ff6: ret
0xf36c9ff7: mov $0xfffffff6,%ecx
0xf36c9ffc: xchg %ax,%ax
0xf36c9fff: call 0xf36a56a0 ; OopMap{off=100}
;*putfield x
; - org.scalapool.bench.MultiVolatileJavaExperiment$Reader::run@15 (line 79)
; {runtime_call}
0xf36ca004: call 0xf6f877a0 ; {runtime_call}
未注释的bar = vfoo（不可扩展，较慢）版本：
[Verified Entry Point]
0xf3771aac: mov %eax,-0x3000(%esp)
0xf3771ab3: push %ebp
0xf3771ab4: sub $0x8,%esp
0xf3771aba: mov 0x68(%ecx),%ebx
0xf3771abd: test %ebx,%ebx
0xf3771abf: jle 0xf3771afe
0xf3771ac1: xor %ebx,%ebx
0xf3771ac3: nopw 0x0(%eax,%eax,1)
0xf3771acc: xchg %ax,%ax
0xf3771ad0: mov 0x6c(%ecx),%ebp
0xf3771ad3: test %ebp,%ebp
0xf3771ad5: je 0xf3771b09
0xf3771ad7: movl $0x1,0x8(%ebp)
-------------------------------------------------
0xf3771ade: mov 0x6c(%ecx),%ebp
0xf3771ae1: mov %ebp,0x70(%ecx)
0xf3771ae4: mov 0x68(%ecx),%edi
0xf3771ae7: inc %ebx
0xf3771ae8: mov %ecx,%eax
0xf3771aea: shr $0x9,%eax
0xf3771aed: movb $0x0,-0x3113c300(%eax) ; OopMap{ecx=Oop off=84}
;*goto
; - org.scalapool.bench.MultiVolatileJavaExperiment$Reader::run@29 (line 83)
-----------------------------------------------
0xf3771af4: test %edi,0xf77ce000 ; {poll}
0xf3771afa: cmp %edi,%ebx
0xf3771afc: jl 0xf3771ad0
0xf3771afe: add $0x8,%esp
0xf3771b01: pop %ebp
0xf3771b02: test %eax,0xf77ce000 ; {poll_return}
0xf3771b08: ret
0xf3771b09: mov $0xfffffff6,%ecx
0xf3771b0e: nop
0xf3771b0f: call 0xf374e6a0 ; OopMap{off=116}
;*putfield x
; - org.scalapool.bench.MultiVolatileJavaExperiment$Reader::run@15 (line 79)
; {runtime_call}
0xf3771b14: call 0xf70307a0 ; {runtime_call}
两个版本的差异在---------之内。我希望在程序集中找到可能导致性能问题的同步指令 - 虽然额外的shift，mov和inc指令可能会影响绝对性能数字，但我看不出如何它们可能会影响可扩展性。
所以，我怀疑这是与存储到类中的字段有关的某种内存问题。另一方面，我也倾向于认为JIT做了一些有趣的事情，因为在一次迭代中，测得的时间 的速度是应有的两倍。
任何人都可以解释这里发生了什么吗？ 请准确并包含支持您声明的参考资料。
谢谢！
编辑：
这是快速（可扩展）版本的字节码：
public void run();
LineNumberTable:
line 77: 0
line 78: 2
line 79: 10
line 83: 18
line 85: 24
Code:
Stack=2, Locals=2, Args_size=1
0: iconst_0
1: istore_1
2: iload_1
3: aload_0
4: getfield #7; //Field sz:I
7: if_icmpge 24
10: aload_0
11: getfield #5; //Field vfoo:Lorg/scalapool/bench/MultiVolatileJavaExperiment$Foo;
14: iconst_1
15: putfield #8; //Field org/scalapool/bench/MultiVolatileJavaExperiment$Foo.x:I
18: iinc 1, 1
21: goto 2
24: return
LineNumberTable:
line 77: 0
line 78: 2
line 79: 10
line 83: 18
line 85: 24
StackMapTable: number_of_entries = 2
frame_type = 252 /* append */
offset_delta = 2
locals = [ int ]
frame_type = 21 /* same */
bar = vfoo的慢速（不可扩展）版本：
public void run();
LineNumberTable:
line 77: 0
line 78: 2
line 79: 10
line 82: 18
line 83: 26
line 85: 32
Code:
Stack=2, Locals=2, Args_size=1
0: iconst_0
1: istore_1
2: iload_1
3: aload_0
4: getfield #7; //Field sz:I
7: if_icmpge 32
10: aload_0
11: getfield #5; //Field vfoo:Lorg/scalapool/bench/MultiVolatileJavaExperiment$Foo;
14: iconst_1
15: putfield #8; //Field org/scalapool/bench/MultiVolatileJavaExperiment$Foo.x:I
18: aload_0
19: aload_0
20: getfield #5; //Field vfoo:Lorg/scalapool/bench/MultiVolatileJavaExperiment$Foo;
23: putfield #6; //Field bar:Lorg/scalapool/bench/MultiVolatileJavaExperiment$Foo;
26: iinc 1, 1
29: goto 2
32: return
LineNumberTable:
line 77: 0
line 78: 2
line 79: 10
line 82: 18
line 83: 26
line 85: 32
StackMapTable: number_of_entries = 2
frame_type = 252 /* append */
offset_delta = 2
locals = [ int ]
frame_type = 29 /* same */
我正在尝试的越多，在我看来这根本与挥发性无关 - 它与写入对象字段有关。我的预感是，这在某种程度上是一个内存争用问题 - 有缓存和错误共享的东西，尽管根本没有明确的同步。
编辑2：
有趣的是，改变这样的程序：
final class Holder {
public Foo bar = null;
}
final class Reader extends Thread {
volatile Foo vfoo = new Foo();
Holder holder = null;
int sz;
public Reader(int _sz) {
sz = _sz;
}
public void run() {
int i = 0;
holder = new Holder();
while (i < sz) {
vfoo.x = 1;
holder.bar = vfoo;
i++;
}
}
}
解决了扩展问题。显然，上面的Holder对象是在线程启动后创建的，并且可能在不同的内存段中分配，然后同时进行修改，而不是修改线程中的字段bar。对象，它在不同的线程实例之间以某种方式“关闭”在内存中。
答案 0 :(得分：3)
这就是我认为正在发生的事情（请记住我不熟悉HotSpot）：
0xf36c9fd0: mov 0x6c(%ecx),%ebp ; vfoo
0xf36c9fd3: test %ebp,%ebp ; vfoo is null?
0xf36c9fd5: je 0xf36c9ff7 ; throw NullPointerException (I guess)
0xf36c9fd7: movl $0x1,0x8(%ebp) ; vfoo.x = 1
0xf36c9fde: mov 0x68(%ecx),%ebp ; sz
0xf36c9fe1: inc %ebx ; i++
0xf36c9fe2: test %edi,0xf7725000 ; safepoint on end of loop
0xf36c9fe8: cmp %ebp,%ebx ; i < sz?
0xf36c9fea: jl 0xf36c9fd0
0xf3771ad0: mov 0x6c(%ecx),%ebp ; vfoo
0xf3771ad3: test %ebp,%ebp ; vfoo is null?
0xf3771ad5: je 0xf3771b09 ; throw NullPointerException (I guess)
0xf3771ad7: movl $0x1,0x8(%ebp) ; vfoo.x = 1
0xf3771ade: mov 0x6c(%ecx),%ebp ; \
0xf3771ae1: mov %ebp,0x70(%ecx) ; / bar = vfoo
0xf3771ae4: mov 0x68(%ecx),%edi ; sz
0xf3771ae7: inc %ebx ; i++
0xf3771ae8: mov %ecx,%eax ;
0xf3771aea: shr $0x9,%eax ; ??? \ Probably replaced later
0xf3771aed: movb $0x0,-0x3113c300(%eax) ; ??? / by some barrier code?
0xf3771af4: test %edi,0xf77ce000 ; safepoint
0xf3771afa: cmp %edi,%ebx ; i < sz ?
0xf3771afc: jl 0xf3771ad0 ;
我认为上述代码代表障碍的原因在于，当采用NullPointerException时，可伸缩版本具有XCHG，其充当障碍，而不可缩放版本具有NOP。
理由是，在vfoo的初始加载和加入线程之间需要进行排序。在易变的情况下，屏障将位于循环内部，因此不需要在其他地方。我不明白的原因是为什么在循环中没有使用XCHG。也许运行时检测到MFENCE支持？
答案 1 :(得分：3)
让我们试着让JVM表现得更“一致”。 JIT编译器真的放弃了测试运行的比较;所以让disable the JIT compiler使用-Djava.compiler=NONE。这无疑会带来性能损失，但有助于消除JIT编译器优化的模糊性和影响。
垃圾收集引入了一系列复杂性。我们使用-XX:+UseSerialGC来使用serial garbage collector。我们还禁用显式垃圾收集并打开一些日志记录以查看何时执行垃圾收集：-verbose:gc -XX:+DisableExplicitGC。最后，让我们使用-Xmx128m -Xms128m分配足够的堆。
现在我们可以使用：
运行测试java -XX:+UseSerialGC -verbose:gc -XX:+DisableExplicitGC -Djava.compiler=NONE -Xmx128m -Xms128m -server -Dsize=50000000 -Dpar=1 MultiVolatileJavaExperiment 10
多次运行测试显示结果非常一致（我在Ubuntu 10.04.3 LTS上使用Oracle Java 1.6.0_24-b07，使用Intel（R）Core（TM）2 Duo CPU P8700 @ 2.53GHz） ，平均大约2050毫秒。如果我注释掉bar = vfoo行，我一直平均大约1280毫秒。使用-Dpar=2运行测试时，bar = vfoo的平均值约为1350毫秒，评论时约为1005毫秒。
+=========+======+=========+
| Threads | With | Without |
+=========+======+=========+
| 1 | 2050 | 1280 |
+---------+------+---------+
| 2 | 1350 | 1005 |
+=========+======+=========+
现在让我们看一下代码，看看我们是否能发现多线程效率低下的原因。在Reader.run()中，符合this的限定变量将有助于明确哪些变量属于本地变量：
int i = 0;
while (i < this.sz) {
this.vfoo.x = 1;
this.bar = this.vfoo;
i++;
}
首先要注意的是while循环包含通过this引用的四个变量。这意味着代码正在访问类的运行时常量池并执行类型检查（通过getfield字节码指令）。让我们更改代码以尝试消除访问运行时常量池，看看我们是否获得了任何好处。
final int mysz = this.sz;
int i = 0;
while (i < mysz) {
this.vfoo.x = 1;
this.bar = this.vfoo;
i++;
}
在这里，我们使用本地mysz变量来访问循环大小，只访问sz到this一次，以进行初始化。运行测试，有两个线程，平均大约1295毫秒;虽然是一个小小的好处，但仍然是一个好处。
查看while循环，我们真的需要两次引用this.vfoo吗？这两个易失性读取创建了两个同步边缘，虚拟机（以及底层硬件）需要管理这些边缘。假设我们确实需要while循环开头的一个同步边缘，我们不需要两个，我们可以使用以下内容：
final int mysz = this.sz;
Foo myvfoo = null;
int i = 0;
while (i < mysz) {
myvfoo = this.vfoo;
myvfoo.x = 1;
this.bar = myvfoo;
i++;
}
平均约为1122毫秒;还是越来越好。那个this.bar参考怎么样？由于我们正在讨论多线程，所以假设while循环中的计算是我们想要获得多线程的好处，this.bar是我们将结果传达给其他人的方式。我们真的不想在this.bar循环完成之后设置while。
final int mysz = this.sz;
Foo myvfoo = null;
Foo mybar = null;
int i = 0;
while (i < mysz) {
myvfoo = this.vfoo;
myvfoo.x = 1;
mybar = myvfoo;
i++;
}
this.bar = mybar;
平均给我们大约857毫秒。 this.vfoo循环中仍有最终while引用。再次假设while循环是我们希望多线程受益的，让我们将this.vfoo移出while循环。
final int mysz = this.sz;
final Foo myvfoo = this.vfoo;
Foo mybar = null;
int i = 0;
while (i < mysz) {
myvfoo.x = 1;
mybar = myvfoo;
i++;
}
final Foo vfoocheck = this.vfoo;
if (vfoocheck != myvfoo) {
System.out.println("vfoo changed from " + myvfoo + " to " + vfoocheck);
}
this.bar = mybar;
现在我们平均大约502毫秒;单线程测试平均大约900毫秒。
那么这告诉我们什么？通过从while循环中推断非局部变量引用，在单线程和双线程测试中都有显着的性能优势。 MultiVolatileJavaExperiment的原始版本衡量的是访问非本地变量50,000,000次的成本，而最终版本则衡量访问本地变量的成本50,000,000次。通过使用局部变量，可以提高Java虚拟机和底层硬件更有效地管理线程缓存的可能性。
最后，让我们正常运行测试（注意，使用500,000,000循环大小而不是50,000,000）：
java -Xmx128m -Xms128m -server -Dsize=500000000 -Dpar=2 MultiVolatileJavaExperiment 10
原始版本的平均值约为1100毫秒，修改后的版本平均值约为10毫秒。
答案 2 :(得分：2)
您实际上并没有写入volatile字段，因此可以在每个线程中缓存volatile字段。
使用volatile可以防止某些编译器优化，在微基准测试中，您可以看到很大的相对差异。
在上面的示例中，注释掉的版本更长，因为它已展开循环以在一个实际循环中放置两个迭代。这几乎可以使性能翻倍。
使用volatile时，您可以看到没有循环展开。
BTW：您可以删除示例中的大量代码，以便于阅读。 ;）
答案 3 :(得分：1)
编辑：这个答案无法经得起考验。
我现在无法对此进行测试（此机器中没有多核CPU），但这是一个理论：Foo实例可能不在同一个缓存行中，但可能是{{1}实例是。
这意味着可以通过写入Reader来解释减速，而不是读取bar，因为写入foo会使另一个核心的高速缓存行无效并导致在缓存之间进行大量复制。注释掉对bar的写入（这是对循环中bar字段的唯一写入）会停止减速，这与此解释一致。
编辑：根据this article，对象的内存布局使得Reader引用将是bar对象布局中的最后一个字段。这意味着很可能与Heap上的下一个对象位于同一缓存行中。由于我不确定在Heap上分配新对象的顺序，我在下面的注释中建议使用引用填充“热”对象类型，这样可以有效地分离对象（至少，我希望它会，但这取决于相同类型的字段在内存中的排序方式。）
答案 4 :(得分：1)
简短：显然，由于GC的卡片标记，答案是假共享。
在这个问题中给出了更广泛的解释：
Array allocation and access on the Java Virtual Machine and memory contention