转载：Java高级-线程同步机制实现

前言

我们可以在计算机上运行各种计算机软件程序。每一个运行的程序可能包括多个独立运行的线程（Thread）。 线程（Thread）是一份独立运行的程序，有自己专用的运行栈。线程有可能和其他线程共享一些资源，比如，内存，文件，数据库等。 当多个线程同时读写同一份共享资源的时候，可能会引起冲突。这时候，我们需要引入线程“同步”机制，即各位线程之间要有个先来后到，不能一窝蜂挤上去抢作一团。 同步这个词是从英文synchronize（使同时发生）翻译过来的。我也不明白为什么要用这个很容易引起误解的词。既然大家都这么用，咱们也就只好这么将就。 线程同步的真实意思和字面意思恰好相反。线程同步的真实意思，其实是“排队”：几个线程之间要排队，一个一个对共享资源进行操作，而不是同时进行操作。

关于线程同步，需要牢牢记住的第一点是：线程同步就是线程排队。同步就是排队。线程同步的目的就是避免线程“同步”执行。这可真是个无聊的绕口令。 
关于线程同步，需要牢牢记住的第二点是：“共享”这两个字。只有共享资源的读写访问才需要同步。如果不是共享资源，那么就根本没有同步的必要。 
关于线程同步，需要牢牢记住的第三点是：只有“变量”才需要同步访问。如果共享的资源是固定不变的，那么就相当于“常量”，线程同时读取常量也不需要同步。至少一个线程修改共享资源，这样的情况下，线程之间就需要同步。 
关于线程同步，需要牢牢记住的第四点是：多个线程访问共享资源的代码有可能是同一份代码，也有可能是不同的代码；无论是否执行同一份代码，只要这些线程的代码访问同一份可变的共享资源，这些线程之间就需要同步。

一、同步锁加在哪里

同步锁加在哪里呢？当然是加在共享资源上了。反应快的读者一定会抢先回答。没错，如果可能，我们当然尽量把同步锁加在共享资源上。一些比较完善的共享资源，比如，文件系统，数据库系统等，自身都提供了比较完善的同步锁机制。我们不用另外给这些资源加锁，这些资源自己就有锁。

但是，大部分情况下，我们在代码中访问的共享资源都是比较简单的共享对象。这些对象里面没有地方让我们加锁。 读者可能会提出建议：为什么不在每一个对象内部都增加一个新的区域，专门用来加锁呢？这种设计理论上当然也是可行的。问题在于，线程同步的情况并不是很普遍。如果因为这小概率事件，在所有对象内部都开辟一块锁空间，将会带来极大的空间浪费。得不偿失。

于是，现代的编程语言的设计思路都是把同步锁加在代码段上。确切的说，是把同步锁加在访问共享资源的代码段上。这一点一定要记住，同步锁是加在代码段上的。

同步锁加在代码段上，就很好地解决了上述的空间浪费问题。但是却增加了模型的复杂度，也增加了我们的理解难度。

二、同步锁加在代码段

现在我们就来仔细分析“同步锁加在代码段上 ”的线程同步模型。 首先，我们已经解决了同步锁加在哪里的问题。我们已经确定，同步锁不是加在共享资源上，而是加在访问共享资源的代码段上。 其次，我们要解决的问题是，我们应该在代码段上加什么样的锁。这个问题是重点中的重点。这是我们尤其要注意的问题：访问同一份共享资源的不同代码段，应该加上同一个同步锁；如果加的是不同的同步锁，那么根本就起不到同步的作用，没有任何意义。

这就是说，同步锁本身也一定是多个线程之间的共享对象。

三、Java语言的synchronized关键字

为了加深理解，举几个代码段同步的例子，synchronized整个语法表现形式：

synchronized(同步锁) {  
// 访问共享资源，需要同步的代码段 
}

这里尤其要注意的就是，同步锁本身一定要是共享的对象。

… f1() { 
      Object lock1 = new Object(); // 产生一个同步锁 
      synchronized(lock1){  
            // 代码段 A 
            // 访问共享资源 resource1 
            // 需要同步 
      } 
}

上面这段代码没有任何意义。因为那个同步锁是在函数体内部产生的。每个线程调用这段代码的时候，都会产生一个新的同步锁。那么多个线程之间，使用的是不同的同步锁。根本达不到同步的目的。同步代码一定要写成如下的形式，才有意义：

public static final Object lock1 = new Object(); 
… f1() { 
      synchronized(lock1){ // lock1 是公用同步锁  
            // 代码段 A 
            // 访问共享资源 resource1 
            // 需要同步 
      }

}

你不一定要把同步锁声明为static或者public，但是你一定要保证相关的同步代码之间，一定要使用同一个同步锁。 讲到这里，你一定会好奇，这个同步锁到底是个什么东西。为什么随便声明一个Object对象，就可以作为同步锁？

在Java里面，同步锁的概念就是这样的。任何一个Object Reference都可以作为同步锁。我们可以把Object Reference理解为对象在内存分配系统中的内存地址。因此，要保证同步代码段之间使用的是同一个同步锁，我们就要保证这些同步代码段的synchronized关键字使用的是同一个Object Reference，同一个内存地址。这也是为什么我在前面的代码中声明lock1的时候，使用了final关键字，这就是为了保证lock1的Object Reference在整个系统运行过程中都保持不变。

一些求知欲强的读者可能想要继续深入了解synchronzied(同步锁)的实际运行机制。Java虚拟机规范中（你可以在google用“JVM Spec”等关键字进行搜索），有对synchronized关键字的详细解释。synchronized会编译成 monitor enter, … monitor exit之类的指令对。Monitor就是实际上的同步锁。每一个Object Reference在概念上都对应一个monitor。

我们继续看几个例子，加深对同步锁模型的理解。

public static final byte[] lock1 = new byte[0]; // 特殊的instance变量

… f1() { 
      synchronized(lock1){ // lock1 是公用同步锁  
            // 代码段 A 
            // 访问共享资源 resource1 
            // 需要同步 
      } 
} 
… f2() { 
      synchronized(lock1){ // lock1 是公用同步锁  
            // 代码段 B 
            // 访问共享资源 resource1 
            // 需要同步 
      } 
}

注：零长度的byte数组对象创建起来将比任何对象都经济，查看编译后的字节码：生成零长度的byte[]对象只需3条操作码，而Object lock = new Object()则需要7行操作码。

上述的代码中，代码段A和代码段B就是同步的。因为它们使用的是同一个同步锁lock1。 如果有10个线程同时执行代码段A，同时还有20个线程同时执行代码段B，那么这30个线程之间都是要进行同步的。

这30个线程都要竞争一个同步锁lock1。同一时刻，只有一个线程能够获得lock1的所有权，只有一个线程可以执行代码段A或者代码段B。其他竞争失败的线程只能暂停运行，进入到该同步锁的就绪（Ready）队列。

每一个同步锁下面都挂了几个线程队列，包括就绪（Ready）队列，待召（Waiting）队列等。比如，lock1对应的就绪队列就可以叫做lock1 - ready queue。每个队列里面都可能有多个暂停运行的线程。注意，竞争同步锁失败的线程进入的是该同步锁的就绪（Ready）队列，而不是后面要讲述的待召队列（Waiting Queue，也可以翻译为等待队列）。就绪队列里面的线程总是时刻准备着竞争同步锁，时刻准备着运行。而待召队列里面的线程则只能一直等待，直到等到某个信号的通知之后，才能够转移到就绪队列中，准备运行。 成功获取同步锁的线程，执行完同步代码段之后，会释放同步锁。该同步锁的就绪队列中的其他线程就继续下一轮同步锁的竞争。成功者就可以继续运行，失败者还是要乖乖地待在就绪队列中。

因此，线程同步是非常耗费资源的一种操作。我们要尽量控制线程同步的代码段范围。同步的代码段范围越小越好 。我们用一个名词“同步粒度 ”来表示同步代码段的范围。

四、同步粒度

在Java语言里面，我们可以直接把synchronized关键字直接加在函数的定义上。比如：

… synchronized … f1() {  
      // f1 代码段 
}

这段代码就等价于

… f1() {  
      synchronized(this){ // 同步锁就是对象本身  
            // f1 代码段  
      } 
}

同样的原则适用于静态（static）函数，比如：

… static synchronized … f1() {  
      // f1 代码段 
}

这段代码就等价于

…static … f1() {  
      synchronized(Class.forName(…)){ // 同步锁是类定义本身  
            // f1 代码段

      } 
}

但是，我们要尽量避免这种直接把synchronized加在函数定义上的偷懒做法。因为我们要控制同步粒度。同步的代码段越小越好。synchronized控制的范围越小越好。 我们不仅要在缩小同步代码段的长度上下功夫，我们同时还要注意细分同步锁。比如，下面的代码：

public static final Object lock1 = new Object(); 
… f1() { 
      synchronized(lock1){ // lock1 是公用同步锁  
            // 代码段 A 
            // 访问共享资源 resource1 
            // 需要同步 
      } 
} 
… f2() { 
      synchronized(lock1){ // lock1 是公用同步锁  
            // 代码段 B 
            // 访问共享资源 resource1 
            // 需要同步 
      } 
} 
… f3() { 
      synchronized(lock1){ // lock1 是公用同步锁  
            // 代码段 C 
            // 访问共享资源 resource2 
            // 需要同步 
      } 
} 
… f4() { 
      synchronized(lock1){ // lock1 是公用同步锁  
             // 代码段 D 
            // 访问共享资源 resource2 
            // 需要同步 
      } 
}

上述的4段同步代码，使用同一个同步锁lock1。所有调用4段代码中任何一段代码的线程，都需要竞争同一个同步锁lock1。 我们仔细分析一下，发现这是没有必要的。 因为f1()的代码段A和f2()的代码段B访问的共享资源是resource1，f3()的代码段C和f4()的代码段D访问的共享资源是resource2，它们没有必要都竞争同一个同步锁lock1。我们可以增加一个同步锁lock2。f3()和f4()的代码可以修改为：

public static final Object lock2 = new Object(); 
… f3() { 
      synchronized(lock2){ // lock2 是公用同步锁  
            // 代码段 C 
            // 访问共享资源 resource2 
            // 需要同步 
      } 
} 
… f4() { 
      synchronized(lock2){ // lock2 是公用同步锁  
            // 代码段 D 
            // 访问共享资源 resource2 
            // 需要同步 
      } 
}

这样，f1()和f2()就会竞争lock1，而f3()和f4()就会竞争lock2。这样，分开来分别竞争两个锁，就可以大大较少同步锁竞争的概率，从而减少系统的开销。

五、信号量（wait()/notify()/notifyAll()使用）

同步锁模型只是最简单的同步模型。同一时刻，只有一个线程能够运行同步代码。 有的时候，我们希望处理更加复杂的同步模型，比如生产者/消费者模型、读写同步模型等。这种情况下，同步锁模型就不够用了。我们需要一个新的模型。这就是我们要讲述的信号量模型。

信号量模型的工作方式如下：线程在运行的过程中，可以主动停下来，等待某个信号量的通知；这时候，该线程就进入到该信号量的待召（Waiting）队列当中；等到通知之后，再继续运行。 很多语言里面，同步锁都由专门的对象表示，对象名通常叫Monitor。 同样，在很多语言中，信号量通常也有专门的对象名来表示，比如，Mutex，Semphore。

信号量模型要比同步锁模型复杂许多。一些系统中，信号量甚至可以跨进程进行同步。另外一些信号量甚至还有计数功能，能够控制同时运行的线程数。 
我们没有必要考虑那么复杂的模型。所有那些复杂的模型，都是最基本的模型衍生出来的。只要掌握了最基本的信号量模型——“等待/通知”模型，复杂模型也就迎刃而解了。

以Java语言为例。Java语言里面的同步锁和信号量概念都非常模糊，没有专门的对象名词来表示同步锁和信号量，只有两个同步锁相关的关键字—volatile和synchronized。 这种模糊虽然导致概念不清，但同时也避免了Monitor、Mutex、Semphore等名词带来的种种误解。我们不必执着于名词之争，可以专注于理解实际的运行原理。 在Java语言里面，任何一个Object Reference都可以作为同步锁。同样的道理，任何一个Object Reference也可以作为信号量。 Object对象的wait()方法就是等待通知，Object对象的notify()方法就是发出通知。 具体调用方法为 ：

（1）等待某个信号量的通知

public static final Object signal = new Object(); 
… f1() { 
      synchronized(singal) { // 首先我们要获取这个信号量。这个信号量同时也是一个同步锁  
            // 只有成功获取了signal这个信号量兼同步锁之后，我们才可能进入这段代码  
             signal.wait(); // 这里要放弃信号量。本线程要进入signal信号量的待召（Waiting）队列 
            // 可怜。辛辛苦苦争取到手的信号量，就这么被放弃了  
            // 等到通知之后，从待召（Waiting）队列转到就绪（Ready）队列里面 
            // 转到了就绪队列中，离CPU核心近了一步，就有机会继续执行下面的代码了。 
            // 仍然需要把signal同步锁竞争到手，才能够真正继续执行下面的代码。命苦啊。  
            … 
      } 
}

需要注意的是，上述代码中的signal.wait()的意思。signal.wait()很容易导致误解。signal.wait()的意思并不是说，signal开始wait，而是说，运行这段代码的当前线程开始wait这个signal对象，即进入signal对象的待召（Waiting）队列。

（2）发出某个信号量的通知

… f2() { 
      synchronized(singal) { // 首先，我们同样要获取这个信号量。同时也是一个同步锁。  
            // 只有成功获取了signal这个信号量兼同步锁之后，我们才可能进入这段代码 
            signal.notify(); // 这里，我们通知signal的待召队列中的某个线程。 
            // 如果某个线程等到了这个通知，那个线程就会转到就绪队列中 
            // 但是本线程仍然继续拥有signal这个同步锁，本线程仍然继续执行 
            // 嘿嘿，虽然本线程好心通知其他线程， 
            // 但是，本线程可没有那么高风亮节，放弃到手的同步锁 
            // 本线程继续执行下面的代码  
            … 
      } 
}

需要注意的是，signal.notify()的意思。signal.notify()并不是通知signal这个对象本身。而是通知正在等待signal信号量的其他线程。

以上就是Object的wait()和notify()的基本用法。 实际上，wait()还可以定义等待时间，当线程在某信号量的待召队列中，等到足够长的时间，就会等无可等，无需再等，自己就从待召队列转移到就绪队列中了。 另外，还有一个notifyAll()方法，表示通知待召队列里面的所有线程。 这些细节问题，并不对大局产生影响。

六、总结

1. wait方法：

该方法属于Object的方法，wait方法的作用是使得当前调用wait方法所在部分（代码块）的线程停止执行，并释放当前获得的调用wait所在的代码块的锁，并在其他线程调用notify或者notifyAll方法时恢复到竞争锁状态（一旦获得锁就恢复执行）。 
调用wait方法需要注意几点：

第一点：wait被调用的时候必须在拥有锁（即synchronized修饰的）的代码块中。 
第二点：恢复执行后，从wait的下一条语句开始执行，因而wait方法总是应当在while循环中调用，以免出现恢复执行后继续执行的条件不满足却继续执行的情况。 
第三点：若wait方法参数中带时间，则除了notify和notifyAll被调用能激活处于wait状态（等待状态）的线程进入锁竞争外，在其他线程中interrupt它或者参数时间到了之后，该线程也将被激活到竞争状态。 
第四点：wait方法被调用的线程必须获得之前执行到wait时释放掉的锁重新获得才能够恢复执行。

2. notify方法和notifyAll方法：

notify方法通知调用了wait方法，但是尚未激活的一个线程进入线程调度队列（即进入锁竞争），注意不是立即执行。并且具体是哪一个线程不能保证。另外一点就是被唤醒的这个线程一定是在等待wait所释放的锁。 
notifyAll方法则唤醒所有调用了wait方法，尚未激活的进程进入竞争队列。

3. synchronized关键字：

第一点：synchronized用来标识一个普通方法时，表示一个线程要执行该方法，必须取得该方法所在的对象的锁。 
第二点：synchronized用来标识一个静态方法时，表示一个线程要执行该方法，必须获得该方法所在的类的类锁。 
第三点：synchronized修饰一个代码块。类似这样：synchronized(obj) { //code.... }。表示一个线程要执行该代码块，必须获得obj的锁。这样做的目的是减小锁的粒度，保证当不同块所需的锁不冲突时不用对整个对象加锁。利用零长度的byte数组对象做obj非常经济。

4. atomic action（原子操作）：

在JAVA中，以下两点操作是原子操作。但是c和c++中并不如此。 
第一点：对引用变量和除了long和double之外的原始数据类型变量进行读写。 
第二点：对所有声明为volatile的变量（包括long和double）的读写。 
另外：在java.util.concurrent和java.util.concurrent.atomic包中提供了一些不依赖于同步机制的线程安全的类和方法。

关于volatile，我们知道，在Java中设置变量值的操作，除了long和double类型的变量外都是原子操作，也就是说，对于变量值的简单读写操作没有必要进行同步。这在JVM 1.2之前，Java的内存模型实现总是从主存读取变量，是不需要进行特别的注意的。而随着JVM的成熟和优化，现在在多线程环境下volatile关键字的使用变得非常重要。在当前的Java内存模型下，线程可以把变量保存在本地内存（比如机器的寄存器）中，而不是直接在主存中进行读写。这就可能造成一个线程在主存中修改了一个变量的值，而另外一个线程还继续使用它在寄存器中的变量值的拷贝，造成数据的不一致。要解决这个问题，只需要像在本程序中的这样，把该变量声明为volatile（不稳定的）即可，这就指示JVM，这个变量是不稳定的，每次使用它都到主存中进行读取。一般说来，多任务环境下各任务间共享的标志都应该加volatile修饰。

Volatile修饰的成员变量在每次被线程访问时，都强迫从共享内存中重读该成员变量的值。而且，当成员变量发生变化时，强迫线程将变化值回写到共享内存。这样在任何时刻，两个不同的线程总是看到某个成员变量的同一个值。

Java语言规范中指出：为了获得最佳速度，允许线程保存共享成员变量的私有拷贝，而且只当线程进入或者离开同步代码块时才与共享成员变量的原始值对比。这样当多个线程同时与某个对象交互时，就必须要注意到要让线程及时的得到共享成员变量的变化。 而volatile关键字就是提示VM：对于这个成员变量不能保存它的私有拷贝，而应直接与共享成员变量交互。

使用建议：在两个或者更多的线程访问的成员变量上使用volatile。当要访问的变量已在synchronized代码块中，或者为常量时，不必使用。 由于使用volatile屏蔽掉了VM中必要的代码优化，所以在效率上比较低，因此一定在必要时才使用此关键字。

5. lock方法和unlock方法：

http://my.oschina.net/xianggao/blog/88477