java 线程(二)：线程同步（synchronized ,wait,notify）

 线程同步

前言：我们上一篇http://davidisok.iteye.com/blog/2105369讲了线程的基本介绍，这一篇主要讲线程的同步，前面我们为线程分配CPU是完全异步的，我们不能控制线程的执行顺序，当所有的线程同时访问同一资源的时候就产生了一致性的问题，java中初步使用synchrnized关键字来锁定资源实现的，既然叫“锁”，那这个关键字的特性也很明了了，它通过锁定资源限定只有一个线程占有该资源并执行线程的动作。

synchronized 关键字

1.线程不同步（异步）的情况

我用一个比较明了的例子来给大家看看。我们设定左右两个球桶通过两个线程来模拟代表线程的一致性，一个线程从左边球桶取出数量的球到另一个桶，另一个线程从右边球桶取出一定数量的放到左边球桶，理论上来将，这是完全没有什么问题的，球桶里面的求数量肯定是保持一致的呀！但往往现实就是这么出其不意，请读者运行下面的代码。

package com.hxw.Threads;
 
publicclass BuketBallGame {
 
   /**
    * 博客来自 http://davidisok.iteye.com/，转载请注明出处
    */
   privateintbucket[]={10000,10000};  //声明两个球桶，用数组代替球桶
   privatestaticbooleanRIGHT_TO_LEFT; //用一个常量来表示转移方向
   publicstaticvoid main(String[] args) {
      // TODO自动生成的方法存根
      new BuketBallGame().doTransfer(); //执行转换
   }
   publicvoid doTransfer(){
      for (int i = 0; i < 10; i++) { //进行10次转换
         new Thread(new TransferThread(!RIGHT_TO_LEFT)).start(); //创建一个线程并执行，将球从右向左转移。
         new Thread(new TransferThread(RIGHT_TO_LEFT)).start();  //创建一个线程并执行，将球从左向右转移。
      }
   }
   publicvoid transfer(boolean direction,int numToTransfer){
      if (direction==RIGHT_TO_LEFT) {
         bucket[0]+=numToTransfer;
         bucket[1]-=numToTransfer;
         System.out.println("左右互转了"+numToTransfer+"个球，两个球桶总数有："+(bucket[0]+bucket[1])+"个球");
      } else {
         bucket[0]-=numToTransfer;
         bucket[1]+=numToTransfer;
         System.out.println("左右互转了"+numToTransfer+"个球，两个球桶总数有："+(bucket[0]+bucket[1])+"个球");
      }
     
   }
privateclass TransferThread implements Runnable{
  
   privatebooleandirection;
   public TransferThread(boolean direction){  
      this.direction=direction;
   }
   @Override
   publicvoid run() {
      for (int i = 0; i < 20; i++) {
         transfer(direction, (int)(Math.random()*2000));
         try {
            Thread.sleep((int)(Math.random()*100)); //随机休眠0-99毫秒，模拟现实球之间的转换
         } catch (InterruptedException e) {
            // TODO自动生成的 catch 块
            e.printStackTrace();
         }
      }
   }
}
}

 

【运行结果】：

左右互转了670个球，两个球桶总数有：20000个球

左右互转了1857个球，两个球桶总数有：20000个球

左右互转了377个球，两个球桶总数有：20000个球

左右互转了505个球，两个球桶总数有：20000个球

左右互转了877个球，两个球桶总数有：20000个球

左右互转了1302个球，两个球桶总数有：20000个球

左右互转了1623个球，两个球桶总数有：20000个球

左右互转了458个球，两个球桶总数有：20000个球

左右互转了1819个球，两个球桶总数有：20379个球

左右互转了1440个球，两个球桶总数有：20379个球

左右互转了923个球，两个球桶总数有：20379个球

左右互转了217个球，两个球桶总数有：20379个球

左右互转了165个球，两个球桶总数有：20379个球

……

可以看出前面几次都是正常的转换，到后面发现求居然多了！理论上是互转，应该不会凭空增多的呀！

原因就是两个线程的异步问题，一个线程可能刚好从一个桶中取出球来还没来得及放，第二个线程就从另一个桶又拿出或者放入了球，导致这两个桶在此时的和并不等于20000。

解决办法：在transfer方法前加synchronized后（public synchronized void transfer(boolean direction,int numToTransfer）你会发现，他们输出的值一直保持为20000.

 

2.关于synchronized 的详细机制和方法强烈建议参考这篇文章

http://davidisok.iteye.com/blog/2105432

3.危险的 volatile 关键字

A.volatile 的使用

volatile 的使用起来非常简单，只要在声明某变量的时候在前面加上关键字volatile，那么线程对该关键字的读操作就始终保持最新的。比如 publicvolatile static int count = 0;

B.它为什么危险？我们首先要说说jvm 线程内部运作原理

在 java 垃圾回收整理一文中，描述了jvm运行时刻内存的分配。其中有一个内存区域是jvm虚拟机栈，每一个线程运行时都有一个线程栈，

线程栈保存了线程运行时候变量值信息。当线程访问某一个对象时候值的时候，首先通过对象的引用找到对应在堆内存的变量的值，然后把堆内存

变量的具体值load到线程本地内存中，建立一个变量副本，之后线程就不再和对象在堆内存变量值有任何关系，而是直接修改副本变量的值，

在修改完之后的某一个时刻（线程退出之前），自动把线程变量副本的值回写到对象在堆中变量。这样在堆中的对象的值就产生变化了。下面一幅图

描述这写交互

 

 

read and load 从主存复制变量到当前工作内存
use and assign 执行代码，改变共享变量值 
store and write 用工作内存数据刷新主存相关内容

其中use and assign 可以多次出现

但是这一些操作并不是原子性，也就是 在read load之后，如果主内存count变量发生修改之后，线程工作内存中的值由于已经加载，不会产生对应的变化，所以计算出来的结果会和预期不一样

对于volatile修饰的变量，jvm虚拟机只是保证从主内存加载到线程工作内存的值是最新的，而不是使用缓存的值

例如假如线程1，线程2 在进行read,load 操作中，发现主内存中count的值都是5，那么都会加载这个最新的值

在线程1堆count进行修改之后，会write到主内存中，主内存中的count变量就会变为6

线程2由于已经进行read,load操作，在进行运算之后，也会更新主内存count的变量值为6

导致两个线程及时用volatile关键字修改之后，还是会存在并发的情况。

C.   引用一篇来自IBM的一篇文章的话（http://www.ibm.com/developerworks/cn/java/j-jtp06197.html#icomments）

Java 语言中的 volatile 变量可以被看作是一种 “程度较轻的 synchronized”；与 synchronized 块相比，volatile 变量所需的编码较少，并且运行时开销也较少，但是它所能实现的功能也仅是 synchronized 的一部分。本文介绍了几种有效使用 volatile 变量的模式，并强调了几种不适合使用 volatile 变量的情形。

锁提供了两种主要特性：互斥（mutual exclusion） 和可见性（visibility）。互斥即一次只允许一个线程持有某个特定的锁，因此可使用该特性实现对共享数据的协调访问协议，这样，一次就只有一个线程能够使用该共享数据。可见性要更加复杂一些，它必须确保释放锁之前对共享数据做出的更改对于随后获得该锁的另一个线程是可见的 —— 如果没有同步机制提供的这种可见性保证，线程看到的共享变量可能是修改前的值或不一致的值，这将引发许多严重问题。

Volatile 变量

Volatile 变量具有 synchronized 的可见性特性，但是不具备原子特性。这就是说线程能够自动发现 volatile 变量的最新值。Volatile 变量可用于提供线程安全，但是只能应用于非常有限的一组用例：多个变量之间或者某个变量的当前值与修改后值之间没有约束。因此，单独使用 volatile 还不足以实现计数器、互斥锁或任何具有与多个变量相关的不变式（Invariants）的类（例如 “start <=end”）。

出于简易性或可伸缩性的考虑，您可能倾向于使用 volatile 变量而不是锁。当使用 volatile 变量而非锁时，某些习惯用法（idiom）更加易于编码和阅读。此外，volatile 变量不会像锁那样造成线程阻塞，因此也很少造成可伸缩性问题。在某些情况下，如果读操作远远大于写操作，volatile 变量还可以提供优于锁的性能优势。

正确使用 volatile 变量的条件

您只能在有限的一些情形下使用 volatile 变量替代锁。要使 volatile 变量提供理想的线程安全，必须同时满足下面两个条件：

a.对变量的写操作不依赖于当前值。

b.该变量没有包含在具有其他变量的不变式中。

实际上，这些条件表明，可以被写入 volatile 变量的这些有效值独立于任何程序的状态，包括变量的当前状态。

第一个条件的限制使 volatile 变量不能用作线程安全计数器。虽然增量操作（x++）看上去类似一个单独操作，实际上它是一个由读取－修改－写入操作序列组成的组合操作，原则上必须以原子方式执行，而 volatile 不能提供必须的原子特性。实现正确的操作需要使 x 的值在操作期间保持不变，而 volatile 变量无法实现这点。（然而，如果将值调整为只从单个线程写入，那么可以忽略第一个条件。）

4.wait()、notify()、notifyAll()的使用和注意事项

  wait(),notify(),notifyAll()不属于Thread类,而是属于Object基础类,也就是说每个对像都有wait(),notify(),notifyAll()的功能.因为都个对像都有锁,锁是每个对像的基础,当然操作锁的方法也是最基础了。
   wait导致当前的线程等待，直到其他线程调用此对象的 notify() 方法或 notifyAll() 方法,或被其他线程中断。wait只能由持有对像锁的线程来调用。

 notify唤醒在此对象监视器上等待的单个线程。如果所有线程都在此对象上等待，则会选择唤醒其中一个线程(随机)。直到当前的线程放弃此对象上的锁，才能继续执行被唤醒的线程。同Wait方法一样，notify只能由持有对像锁的线程来调用.notifyall也一样，不同的是notifyall会唤配所有在此对象锁上等待的线程。

"只能由持有对像锁的线程来调用"说明wait方法与notify方法必须在同步块内执行,即synchronized(obj)之内.再者synchronized代码块内没有锁是寸步不行的，所以线程要继续执行必须获得锁。相辅相成。

下面我做一个明朗的消费者和生产者模型来看看他们的用法

 

package com.hxw.Amazing;
 

public class ProducerConsumeGameSynchro {  
   
   /** 
    * @param args 
    */  
   public static void main(String[] args) {  
      Bucket bucket=new Bucket(); //构造篮子  
      new Thread(new Producer(bucket)).start();  
      new Thread(new Consumer(bucket)).start();  
   }  
   
}  
   
final class Consumer implements Runnable{  
   private Bucket bucket;  
   public Consumer(Bucket bucket){  
      this.bucket=bucket;  
   }  
   @Override  
   public void run() {  
      for (int i = 0; i < 10; i++) {  
         bucket.get();  
      }  
   }  
    
}  
   
final class Producer implements Runnable{  
   private Bucket bucket;  
   public Producer(Bucket bucket){  
      this.bucket=bucket;  
   }  
   @Override  
   public void run() {  
      for (int i = 0; i < 10; i++) {    //来回十次交易  
         bucket.put((int)(Math.random()*1000));  
      }  
   }  
}  
class Bucket{  
   private int packOdBalls;  
   private boolean available=false;  
    
   public synchronized int get()  {  //消费者从篮子里面取出球  
      if(available==false){       //如果没有就等着  
         try {  
            System.out.println("消费者：暂时没有球可以消费我就等着...");  
            wait();  
         } catch (InterruptedException e) {  
            // TODO自动生成的 catch 块  
            e.printStackTrace();  
         }  
      }                        //有的话就取出来  
      System.out.println("消费者获得了"+packOdBalls+"个球");  
      available=false;  
      notify();  
      return packOdBalls;  
   }  
   
   public synchronized void put(int packOdBalls)  {  //生产者将生产球并放入到篮子里面  
      if (available) {  
         try {  
            System.out.println("生产者：既然篮子里面已经有球了我就消费完了再生产吧！");  
            wait();  
         } catch (InterruptedException e) {  
            // TODO自动生成的 catch 块  
            e.printStackTrace();  
         }  
      }  
      this.packOdBalls=packOdBalls;  
      available=true;  
      System.out.println("生产者放进去了"+packOdBalls+"个球");  
      notify();  
   }  
    
}  

 

【运行结果:】

生产者放进去了213个球

生产者：既然篮子里面已经有球了我就消费完了再生产吧！

消费者获得了213个球

消费者：暂时没有球可以消费我就等着...

生产者放进去了750个球

生产者：既然篮子里面已经有球了我就消费完了再生产吧！

消费者获得了750个球

消费者：暂时没有球可以消费我就等着...

生产者放进去了337个球

消费者获得了337个球

消费者：暂时没有球可以消费我就等着...

生产者放进去了105个球

消费者获得了105个球

消费者：暂时没有球可以消费我就等着...

生产者放进去了409个球

生产者：既然篮子里面已经有球了我就消费完了再生产吧！

消费者获得了409个球

消费者：暂时没有球可以消费我就等着...

生产者放进去了284个球

消费者获得了284个球

消费者：暂时没有球可以消费我就等着...

生产者放进去了985个球

消费者获得了985个球

消费者：暂时没有球可以消费我就等着...

生产者放进去了396个球

消费者获得了396个球

消费者：暂时没有球可以消费我就等着...

生产者放进去了103个球

消费者获得了103个球

消费者：暂时没有球可以消费我就等着...

生产者放进去了909个球

消费者获得了909个球

 

还没完！  2014-8-22 增加一段

如果线程进入由线程已经拥有的监控器保护的 synchronized 块，就允许线程继续进行。当线程退出第二个（或者后续）synchronized 块的时候，不释放锁，只有线程退出它进入的监控器保护的第一个 synchronized 块时，才释放锁。

这是我在其他博客里面摘到的一句话，不好懂？没关系，看看下面通俗的解释。提个问题：如果已经拥有该对象的锁的线程再次进入该锁可以吗？肯定可以！但是线程需要再锁一次吗？稍微想想就知道，肯定不需要，自己都有这个锁了还锁一遍干嘛，一般应该没有人在保险柜里面再放个保险柜吧！这一点经常体现在当一个类中有几个synchronied方法时，我从这个方法到同对象中另一个synchronized方法去，这时也是不需要锁的！，但是又但是，这样进了几层锁，synchronized不是自动释放吗，那它怎么释放？答案是，在获得锁的那一次释放，正所谓，解铃还须系铃人啊！