JVM线程资源同步及交互机制

1  JVM线程资源同步及交互机制

Java程序采用多线程的方式来支撑大量的并发请求处理，程序在多线程方式执行的情况下，复杂程度远高于单线程串行执行的程序。尤其是在多核或多 CPU系统中，多线程执行的程序所带来的最明显的问题是线程之间共同管理的资源的竞争及线程之间的交互。JVM的线程实现及调度方式（抢占式、协作式）取决于操作系统，超出了本书范围，本节中仅介绍JVM线程资源同步机制和线程之间的交互机制。

1.1  线程资源同步机制

首先来看典型获取下一ID的程序：

 
 

  
  int  i = 0 ;  
public int getNextId(){  
    return i++;  
} 

 
 

以下为上面程序在JVM中的执行步骤：

1） JVM首先在main memory（JVM堆） 给i分配一个内存存储场所，并存储其值0；

2）线程启动后，会自动分配一片working memory区（通常是操作数栈），当线程执行到return i++时，JVM中并不是简单的一个步骤就可以完成的。i++动作在JVM中分为装载i、读取i、进行i+1操作、存储i及写入i五个步骤才得以完成。

装载i

线程发起一个装载i的请求给jvm线程执行引擎，引擎接收请求后会向main memory发起一个read i的指令。

当read i执行完毕后，一段时间线程会将i的值从main memory区复制到working memory区中。

读取i

此步负责的是从main memory中读取i。

进行i+1操作

此步由线程完成。

存储i

将i+1的值赋给i，然后存储到working memory中。

写入i

一段时间后i的值会写回到main memory中。

从以上步骤描述来看，这里面最关键的问题有两点：一是working memory中i值和main memory中的i值的同步是需要时间的；二是i++由多个操作组成。只要多个线程在这个时间段内同时执行了操作，就会出现获取i值相同的现象。举个简单的例子：假设线程A已执行i+1操作，但尚未执行完写入i步骤，线程B就完成了装载i的过程，那么当线程B执行完毕时，其得到的值和A就是一样的了，这是以上代码在多线程执行时会出现获取相同值的原因。

JVM把对于working memory的操作分为了use、assign、load、store、lock和unlock，对于working memory的操作的指令由线程发出，对于main memory的操作分为了read、write、lock和unlock；对于main memory的操作的指令由线程执行引擎发出 ，其含义分别为：

use

use由线程发起，需要完成将变量的值从working memory中复制到线程执行引擎中。

assign

assign由线程发起，需要完成将变量值复制到线程的working memory中，例如a=i，这时线程就会发起一个assign动作。

load

load由线程发起，需要完成将main memory中read到的值复制到working memory中。

store

store由线程发起，负责将变量的值从working memory中复制到main memory中，并等待main memory通过write动作写入此值。

 

read

read由main memory发起，负责从main memory中读取变量的值。

write

write由main memory发起，负责将working memory的值写入到main memory中。

lock

lock动作由线程发起，同步操作main memory，给对象加上锁。

unlock

unlock动作由线程发起，同步操作main memory，去除对象的锁。

JVM中保证以下操作是顺序的：

1）同一个线程上的操作一定是顺序执行的；

2）对于main memory上的同一个变量的操作一定是顺序执行的，也就是不可能两个请求同时读取变量值；

3）对于加了锁的main memory上的对象操作，一定是顺序执行的，也就是两个以上加了lock的操作，同时肯定只有一个是在执行的。

为了避免资源操作的脏数据问题，JVM提供了synchronized关键字、volatile关键字和lock/unlock机制。

采用synchronized关键字改造上面的代码为：

 
 

  
  public synchronized int getNextId(){  
    return i++;  
}   

 
 

当多线程执行此段代码时，线程A执行到getNextId()方法，JVM知道该方法上有synchronized关键字，于是在执行其他动作前首先按照对象的实例ID加上一个lock。然后再继续执行return i++，而此时如线程B并发访问getNextId()方法，JVM观察到这个对象的实例ID上有lock，于是将线程B放入等待执行的队列中，只有当线程A的return i++执行完毕后，JVM才会释放对象实例ID上的lock，重新标记为unlock。这时当下次线程调度到线程B时，线程B才得以执行 getNextId()方法，由于这个过程是串行的，因此可以保证每个线程getNextId都是不一样的值。

synchronized除了可直接写在方法上外，也可直接定义在对象上，区别仅在于JVM会根据这些情况来决定lock标记是打在什么上。需要注意的是，如果synchronized是标记在一个static方法上，那么执行时锁的粒度为当前Class。

lock/unlock机制的原理和synchronized相同，synchronized、lock/unlock机制都可用于保证某段代码执行的原子性，由于锁会阻塞其他线程同样需要锁的部分的执行，因此在使用锁机制时要避免死锁的产生，尤其是在多把锁的情况下，例如：

 
 

  
  private Object  a = new  Object();  
private Object  b = new  Object();  
public void callAB(){  
    synchronized(b){  
        synchronized(a){  
            // Do something;  
        }  
    }  
}  

public void executeAB(){  
    synchronized(a){  
        synchronized(b){  
            // Do something;  
        }  
    }  
}  

 
 

当上面的callAB和executeAB被两个线程同时执行时，就会产生死锁的现象，导致系统挂起。这是一个使用synchronized的例子，对于直接使用lock/unlock来编写的多线程程序而言，一定要保证lock和unlock是成对出现的，并且要保证lock后程序执行完毕时一定要unlock，否则就有线程会出现锁饿死的现象。

volatile的机制有所不同，它仅用于控制线程中对象的可见性，但并不能保证在此对象上操作的原子性。就像上面i++的场景，即使把i定义为 volatile也是没用的，对于定义为volatile的变量，线程不会将其从main memory复制到work memory中，而是直接在main memory中进行操作。它的代价虽然比synchronized、lock/unlock低，但用起来要非常小心，毕竟它不能保证操作的原子性。

有了synchronized、lock/unlock及volatile后，在Java中就可以很好地控制多线程程序中资源的竞争。但由于这三个机制对于系统的性能都是有影响的，例如会将操作由并行化变为串行化，因此需要根据合理的需求对线程中的资源进行同步。

 

1.2  线程资源交互机制

        线程之间除了会产生资源的竞争外，还会有交互的需求，例如最典型的连接池，连接池中通常都会有get和return两个方法，return的时候需要将连接返回到缓存列表中，并将可使用的连接数加1，而get方法在判断可使用的连接数已经到了0后，需要进入一个等待状态，当有连接返回到连接池时，应该通知下get方法，不需要再等待了，如果没有这个交互机制的话，就只能在get方法中不断的轮循判断可使用的连接数的值了，JVM提供了wait/notify/notifyAll这样的方式来支持这类需求，在基于Object的wait/notify/notifyAll实现连接池时典型的代码如下：

 
 

  
  public Connection get(){  
   synchronized(this){
      if(free>0){
         free--;
         return cacheConnections.poll();
      }
      else{
      this.wait();
      }
   }
}
public void close(Connection conn){
    synchronized(this){
       free++;
       cacheConnections.offer(conn);
       this.notifyAll();
    }
}
 
 

        调用Object的wait方法可以让当前线程进入等待状态，只有当其他线程调用了此Object的notify、或notifyAll方法、或wait(毫秒数)到达了指定的时间后，才会被激活继续执行，notify只是随机找wait此Object的一个线程，而notifyAll则是通知wait此Object的所有线程，在Sun JDK中，object.wait还有可能被假唤醒，因此通过在object.wait被唤醒后，应再次确认需要等待的状态是否变更了，如未变更，则继续进入wait状态，这种做法通称为double check。

        当线程调用了对象的wait方法后，JVM线程执行引擎会将此线程放入一个wait sets中，并释放此对象的锁，在wait sets中的线程将不会被JVM线程执行引擎调度执行，当其他线程调用了此对象的notify方法时，会从wait sets中随机找一个等待在此对象上的线程，并将其从wait sets中删除，这样JVM线程执行引擎就可以再次调度执行此线程了，当调用的为notifyAll方法时，则会删除wait sets上所有等待在此对象上的线程，在删除完毕后释放对象锁。

        在Sun JDK 5.0的版本中，增加了并发包，其中提供了更多的方式来支持线程间的交互，例如Semphore的acquire和release、Condition的await和signal、CountDownLatch的await和countDown等。