双 IF 魔符

转自IBM developerWorks 中国

如果您发现您的代码 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 魔符”的原因所在。

双 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 可以采用管道技术处理以上用 ** 标出的代码：

线程 A 进入锁住的那部分代码。

线程 B 对第一个 if 语句求值并计算指针的值（在最后的 else 子句中）。

线程 B 得到“指针”（由于线程 A 还没有指定它，所以是垃圾）的值。

在线程 A 完成并解锁的同时，线程 B 将计算第一个 if 的值。

解锁导致“flag”的值被清除（意味着线程 B 在它的高速缓存中具有的任何值都是无效的）。

线程 B 计算好第一个 if 子句的值，当然，现在它发现值为 true。

现在线程 B 使用前面那个是垃圾的指针值。

这就是 Java 双 if 魔符。虽然其它的语言（比如 C/C++）让您通过使用语言本机功能强制执行的次序来解决这个问题，Java 语言却不行。为了安全的执行上述示例，您必须把所有代码封装在一个 synchronize 子句中，或者寻找另外一种写法。