如果您发现您的代码 99.99% 的时间在单 CPU 上运行，但是当您按比例增加到两个或更多个 CPU 时，它很快就会崩溃，那么这一珍品正适合您。
这一问题不仅与 Java 代码在一个对称多处理器（symmetric multiple processor，SMP）平台上运行的复杂程度有关，还与管道技术对“受保护的（protected）”代码的影响有关。尽管您的代码应该高效而且一致始终都很重要，但是由于 SMP 这样的平台将夸大存储模型中的一致性问题，因此，当您的应用程序在 SMP 平台上运行时尤其是如此。
虽然双 if 子句是解决多线程应用程序所带来的问题的一般方法，但它使您遇到“弱一致性”模型（CPU 管道技术、预测执行（speculative execution）等等）所带来的问题（尤其是关于 SMP 系统）。因此，这个珍品简而言之就是：如果您的应用程序将在 SMP 系统上运行，那么请不要在您的代码中使用双 if 逻辑。现在，让我们仔细看一下这个问题的原因和机理。
双 if 逻辑
首先，请考虑一下把指针指向资源的下列代码，其中 flag 表示有无该资源：
IF flag == 0
{
// no resource
set flag
acquire resource
set pointer to resource
}
ELSE
set pointer to resource
如果这段代码是可重入的（即，可以由多个线程运行它），那么它是非常危险的。请考虑一下如果一个线程在 if 子句的中途，此时另外一个线程发现 flag 已经被设置了，于是它就试图去设置一个指针指向第一个线程还未分配的资源，结果会怎样呢？幸运的是，这个问题很容易纠正，如下所示：
IF flag == 0
{
// no resource
acquire resource ----- A
set pointer to resource
set flag
}
ELSE
set pointer to resource
但是，现在我们又发现另外一个问题：一个线程阻塞在 A 点，另一个线程却因发现 flag 被设为 0 而继续执行。在这种情况下，这两个线程都执行同一段代码分配资源 — 这根本不是我们所希望的！然而，解决方法又是众所周知：我们只要在执行获取资源的代码时，封锁所有其它线程，如下所示：
ENTER LOCK
IF flag == 0
{
// no resource
acquire resource
set pointer to resource
set flag
}
ELSE
set pointer to resource
LEAVE LOCK
（请注意我使用了 LOCK 这一术语来保持示例简单。当然，在 Java 代码中是用 synchronize 子句内的同步代码来表示它）。
现在我们的代码是线程安全的，但还不是高效的。获取锁（或 Java 术语中的管程（monitor））需要很多时间，而且锁中的代码比我们需要的要多。为了纠正这一点，我们把代码改写成下面这样：
IF flag == 0
{
// no resource ----- A
ENTER LOCK
acquire resource
set pointer to resource
set flag
LEAVE LOCK
}
ELSE
set pointer to resource
这几乎奏效了，但是我们又引入了前面的问题，一个线程在 A 点被中止，而另一个线程插入进来，因此造成了 CPU 的混乱。为了纠正这一点，我们使用著名的双 if 子句：
IF flag == 0
{
// no resource ----- A
ENTER LOCK
IF flag == 0
acquire resource
set pointer to resource
set flag
ELSE
set pointer to resource
LEAVE LOCK
}
ELSE
set pointer to resource
通过添加双 if 子句，我们已经尽了最大努力使代码线程安全而且高效。许多高级编程技术方面的书中都推荐使用双 if 逻辑来解决线程争用。但是双 if 逻辑在多个线程可以同时执行的 SMP 机器上并不安全。
您会说，可是某一时刻在“锁住的”那部分代码中只会有一个线程，那么会出什么问题呢？很多！这就是把这一技巧叫做“双 if 魔符”的原因所在。
[1] [2] 下一页
双 if 魔符请考虑一下管道技术对上面这段代码的影响：
由于 CPU 看不到任何依赖，所以可以以任何次序执行 if 子句里的代码。这会影响到下面用 * 标出的指令。
如果 flag 被设为 0，那么与先计算“flag”再计算 flag 非 0 情况下的指针相比，计算指针（可能会是垃圾）并抛掉它可能是更高效的做法。所以，CPU 可以采用管道技术处理下面用 ** 标出的指令。
以下又是这些代码，为说明上述观点而加上了标记：
**IF flag == 0
{
// no resource
ENTER LOCK
IF flag == 0
*acquire resource
*set pointer to resource
*set flag
ELSE
set pointer to resource
LEAVE LOCK
}
ELSE
**set pointer to resource
尽管这似乎有点奇怪，但上面的代码可能会象下面这样执行：
**set pointer to resource
**IF flag == 0
{
// no resource
ENTER LOCK
set pointer to resource
IF flag == 0
*set flag
*acquire resource ----- A
*set pointer to resource
ELSE
LEAVE LOCK
}
ELSE
正如您所见到的，我们很敏感的代码仍在锁中，但是现在在分配资源之前设置 flag。因此，请想象一下线程 A 正在 A 点附近执行，此刻另外一个线程到来了。在 SMP 机器上，第二个线程可以在另一个 CPU 上与第一个线程同时执行；这个线程看到 flag 没有被设置成 0（因为它在锁的外部），它可以继续把指针指向未分配资源 — 上当了！
此外，即使代码按我们所写的执行，我们仍然没有免除灾难，原因在于 CPU 可以采用管道技术处理以上用 ** 标出的代码：
1. 线程 A 进入锁住的那部分代码。
2.线程 B 对第一个 if 语句求值并计算指针的值（在最后的 else 子句中）。
3.线程 B 得到“指针”（由于线程 A 还没有指定它，所以是垃圾）的值。
4.在线程 A 完成并解锁的同时，线程 B 将计算第一个 if 的值。
5.解锁导致“flag”的值被清除（意味着线程 B 在它的高速缓存中具有的任何值都是无效的）。
6.线程 B 计算好第一个 if 子句的值，当然，现在它发现值为 true。
7.现在线程 B 使用前面那个是垃圾的指针值。
这就是 Java 双 if 魔符。虽然其它的语言（比如 C/C++）让您通过使用语言本机功能强制执行的次序来解决这个问题，Java 语言却不行。为了安全的执行上述示例，您必须把所有代码封装在一个 synchronize 子句中，或者寻找另外一种写法。
（出处：http://www.sheup.com）
上一页 [1] [2]
正如您所见到的，我们很敏感的代码仍在锁中，但是现在在分配资源之前设置 flag。因此，请想象一下线程 A 正在 A 点附近执行，此刻另外一个线程到来了。在 SMP 机器上，第二个线程可以在另一个 CPU 上与第一个线程同时执行；这个线程看到 flag 没有被设置成 0（因为它在锁的外部），它可以继续把指针指向未分配资源 — 上当了！
此外，即使代码按我们所写的执行，我们仍然没有免除灾难，原因在于 CPU 可以采用管道技术处理以上用 ** 标出的代码：
1. 线程 A 进入锁住的那部分代码。
2.线程 B 对第一个 if 语句求值并计算指针的值（在最后的 else 子句中）。
3.线程 B 得到“指针”（由于线程 A 还没有指定它，所以是垃圾）的值。
4.在线程 A 完成并解锁的同时，线程 B 将计算第一个 if 的值。
5.解锁导致“flag”的值被清除（意味着线程 B 在它的高速缓存中具有的任何值都是无效的）。
6.线程 B 计算好第一个 if 子句的值，当然，现在它发现值为 true。
7.现在线程 B 使用前面那个是垃圾的指针值。
这就是 Java 双 if 魔符。虽然其它的语言（比如 C/C++）让您通过使用语言本机功能强制执行的次序来解决这个问题，Java 语言却不行。为了安全的执行上述示例，您必须把所有代码封装在一个 synchronize 子句中，或者寻找另外一种写法。
（出处：http://www.sheup.com/）
上一页 [1] [2] [3]