Java多线程同步问题的探究

众所周知，在Java多线程编程中，一个非常重要的方面就是线程的同步问题。
关于线程的同步，一般有以下解决方法：

1. 在需要同步的方法的方法签名中加入synchronized关键字。

2. 使用synchronized块对需要进行同步的代码段进行同步。

3. 使用JDK 5中提供的java.util.concurrent.lock包中的Lock对象。

另外，为了解决多个线程对同一变量进行访问时可能发生的安全性问题，我们不仅可以采用同步机制，更可以通过JDK 1.2中加入的ThreadLocal来保证更好的并发性。

本篇中，将详细的讨论Java多线程同步机制，并对ThreadLocal做出探讨。

大致的目录结构如下：

一、线程的先来后到——问题的提出：为什么要有多线程同步？Java多线程同步的机制是什么？
二、给我一把锁，我能创造一个规矩——传统的多线程同步编程方法有哪些？他们有何异同？
三、Lock来了，大家都让开—— Java并发框架中的Lock详解。
四、合作，原来如此简单——Java多线程协作（wait、notify、notifyAll）
五、你有我有全都有—— ThreadLocal如何解决并发安全性？
六、总结——Java线程安全的几种方法对比。

一、线程的先来后到

我们来举一个Dirty的例子：某餐厅的卫生间很小，几乎只能容纳一个人如厕。为了保证不受干扰，如厕的人进入卫生间，就要锁上房门。我们可以把卫生间想象成是共享的资源，而众多需要如厕的人可以被视作多个线程。假如卫生间当前有人占用，那么其他人必须等待，直到这个人如厕完毕，打开房门走出来为止。这就好比多个线程共享一个资源的时候，是一定要分出先来后到的。
转载注明出处：http://x-
spirit.javaeye.com/、http:
//www.blogjava.net/zhangwei217245/

有人说：那如果我没有这道门会怎样呢？让两个线程相互竞争，谁抢先了，谁就可以先干活，这样多好阿？但是我们知道：如果厕所没有门的话，如厕的人一起涌向厕所，那么必然会发生争执，正常的如厕步骤就会被打乱，很有可能会发生意想不到的结果，例如某些人可能只好被迫在不正确的地方施肥……
转载注明出处：http://x-spirit.javaeye.com/、http://www.blogjava.net/zhangwei217245/

正是因为有这道门，任何一个单独进入如厕的人都可以顺利的完成他们的如厕过程，而不会被干扰，甚至发生以外的结果。这就是说，如厕的时候要讲究先来后到。
转载注明出处：http://x-spirit.javaeye.com/、http://www.blogjava.net/zhangwei217245/

那么在Java 多线程程序当中，当多个线程竞争同一个资源的时候，如何能够保证他们不会产生“打架”的情况呢？有人说是使用同步机制。没错，像上面这个例子，就是典型的同步案例，一旦第一位开始如厕，则第二位必须等待第一位结束，才能开始他的如厕过程。一个线程，一旦进入某一过程，必须等待正常的返回，并退出这一过程，下一个线程才能开始这个过程。这里，最关键的就是卫生间的门。其实，卫生间的门担任的是资源锁的角色，只要如厕的人锁上门，就相当于获得了这个锁，而当他打开锁出来以后，就相当于释放了这个锁。

也就是说，多线程的线程同步机制实际上是靠锁的概念来控制的。那么在Java程序当中，锁是如何体现的呢？
转载注明出处：http://x-
spirit.javaeye.com/、http:
//www.blogjava.net/zhangwei217245/

让我们从JVM的角度来看看锁这个概念：

在Java程序运行时环境中，JVM需要对两类线程共享的数据进行协调：
1）保存在堆中的实例变量
2）保存在方法区中的类变量

这两类数据是被所有线程共享的。
（程序不需要协调保存在Java 栈当中的数据。因为这些数据是属于拥有该栈的线程所私有的。）

在java虚拟机中，每个对象和类在逻辑上都是和一个监视器相关联的。
对于对象来说，相关联的监视器保护对象的实例变量。

对于类来说，监视器保护类的类变量。
转载注明出处：http://x-spirit.javaeye.com/、http://www.blogjava.net/zhangwei217245/

（如果一个对象没有实例变量，或者一个类没有变量，相关联的监视器就什么也不监视。）

为了实现监视器的排他性监视能力，java虚拟机为每一个对象和类都关联一个锁。代表任何时候只允许一个线程拥有的特权。线程访问实例变量或者类变量不需锁。

但是如果线程获取了锁，那么在它释放这个锁之前，就没有其他线程可以获取同样数据的锁了。（锁住一个对象就是获取对象相关联的监视器）

类锁实际上用对象锁来实现。当虚拟机装载一个class文件的时候，它就会创建一个java.lang.Class类的实例。当锁住一个对象的时候，实际上锁住的是那个类的Class对象。

一个线程可以多次对同一个对象上锁。对于每一个对象，java虚拟机维护一个加锁计数器，线程每获得一次该对象，计数器就加1，每释放一次，计数器就减1，当计数器值为0时，锁就被完全释放了。
转载注明出处：http://x-spirit.javaeye.com/、http://www.blogjava.net/zhangwei217245/

java编程人员不需要自己动手加锁，对象锁是java虚拟机内部使用的。

在java程序中，只需要使用synchronized块或者synchronized方法就可以标志一个监视区域。当每次进入一个监视区域时，java虚拟机都会自动锁上对象或者类。
转载注明出处：http://x-spirit.javaeye.com/、http://www.blogjava.net/zhangwei217245/

看到这里，我想你们一定都疲劳了吧？o(∩_∩)o...哈哈。让我们休息一下，但是在这之前，请你们一定要记着：
当一个有限的资源被多个线程共享的时候，为了保证对共享资源的互斥访问，我们一定要给他们排出一个先来后到。而要做到这一点，对象锁在这里起着非常重要的作用。
转载注明出处：http://x-spirit.javaeye.com/、http://www.blogjava.net/zhangwei217245/

 

 

很多人都知道，在Java多线程编程中，有一个重要的关键字，synchronized。但是很多人看到这个东西会感到困惑：“都说同步机制是通过对象锁来实现的，但是这么一个关键字，我也看不出来Java程序锁住了哪个对象阿？“



没错，我一开始也是对这个问题感到困惑和不解。不过还好，我们有下面的这个例程：

 1  public   class  ThreadTest  extends  Thread {

 2 

 3       private   int  threadNo;

 4 

 5       public  ThreadTest( int  threadNo) {

 6           this .threadNo  =  threadNo;

 7      }

 8 

 9       public   static   void  main(String[] args)  throws  Exception {

10           for  ( int  i  =   1 ; i  <   10 ; i ++ ) {

11               new  ThreadTest(i).start();

12              Thread.sleep( 1 );

13          }

14      }

15 

16      @Override

17       public   synchronized   void  run() {

18           for  ( int  i  =   1 ; i  <   10000 ; i ++ ) {

19              System.out.println( " No. "   +  threadNo  +   " : "   +  i);

20          }

21      }

22  }

这个程序其实就是让10个线程在控制台上数数，从1数到9999。理想情况下，我们希望看到一个线程数完，然后才是另一个线程开始数数。但是这个程序的执行过程告诉我们，这些线程还是乱糟糟的在那里抢着报数，丝毫没有任何规矩可言。



但是细心的读者注意到：run方法还是加了一个synchronized关键字的，按道理说，这些线程应该可以一个接一个的执行这个run方法才对阿。



但是通过上一篇中，我们提到的，对于一个成员方法加synchronized关键字，这实际上是以这个成员方法所在的对象本身作为对象锁。在本例中，就是以ThreadTest类的一个具体对象，也就是该线程自身作为对象锁的。一共十个线程，每个线程持有自己 线程对象的那个对象锁。这必然不能产生同步的效果。换句话说，如果要对这些线程进行同步，那么这些线程所持有的对象锁应当是共享且唯一的！

转载注明出处：http://x- spirit.javaeye.com/、http: //www.blogjava.net/zhangwei217245/
我们来看下面的例程：

 1  public   class  ThreadTest2  extends  Thread {

 2 

 3       private   int  threadNo;

 4       private  String lock;

 5 

 6       public  ThreadTest2( int  threadNo, String lock) {

 7           this .threadNo  =  threadNo;

 8           this .lock  =  lock;

 9      }

10 

11       public   static   void  main(String[] args)  throws  Exception {

12          String lock  =   new  String( " lock " );

13           for  ( int  i  =   1 ; i  <   10 ; i ++ ) {

14               new  ThreadTest2(i, lock).start();

15              Thread.sleep( 1 );

16          }

17      }

18 

19       public   void  run() {

20           synchronized  (lock) {

21               for  ( int  i  =   1 ; i  <   10000 ; i ++ ) {

22                  System.out.println( " No. "   +  threadNo  +   " : "   +  i);

23              }

24          }

25      }

26  }

我们注意到，该程序通过在main方法启动10个线程之前，创建了一个String类型的对象。并通过ThreadTest2的构造函数，将这个对象赋值给每一个ThreadTest2线程对象中的私有变量lock。根据Java方法的传值特点，我们知道，这些线程的lock变量实际上指向的是堆内存中的同一个区域，即存放main函数中的lock变量的区域。

转载注明出处：http://x- spirit.javaeye.com/、http: //www.blogjava.net/zhangwei217245/
程序将原来run方法前的synchronized关键字去掉，换用了run方法中的一个synchronized块来实现。这个同步块的对象锁，就是main方法中创建的那个String对象。换句话说，他们指向的是同一个String类型的对象，对象锁是共享且唯一的！

转载注明出处：http://x- spirit.javaeye.com/、http: //www.blogjava.net/zhangwei217245/
于是，我们看到了预期的效果：10个线程不再是争先恐后的报数了，而是一个接一个的报数。

转载注明出处：http://x- spirit.javaeye.com/、http: //www.blogjava.net/zhangwei217245/
再来看下面的例程：

 1  public   class  ThreadTest3  extends  Thread {

 2 

 3       private   int  threadNo;

 4       private  String lock;

 5 

 6       public  ThreadTest3( int  threadNo) {

 7           this .threadNo  =  threadNo;

 8      }

 9 

10       public   static   void  main(String[] args)  throws  Exception {

11           // String lock = new String("lock");

12           for  ( int  i  =   1 ; i  <   20 ; i ++ ) {

13               new  ThreadTest3(i).start();

14              Thread.sleep( 1 );

15          }

16      }

17 

18       public   static   synchronized   void  abc( int  threadNo) {

19           for  ( int  i  =   1 ; i  <   10000 ; i ++ ) {

20             

21                  System.out.println( " No. "   +  threadNo  +   " : "   +  i);

22                 

23             

24                 

25             

26          }

27      }

28 

29       public   void  run() {

30          abc(threadNo);

31      }

32  }

细心的读者发现了：这段代码没有使用main方法中创建的String对象作为这10个线程的线程锁。而是通过在run方法中调用本线程中一个静态的同步方法abc而实现了线程的同步。我想看到这里，你们应该很困惑：这里synchronized静态方法是用什么来做对象锁的呢？

转载注明出处：http://x- spirit.javaeye.com/、http: //www.blogjava.net/zhangwei217245/
我们知道，对于同步静态方法，对象锁就是该静态放发所在的类的Class实例，由于在JVM中，所有被加载的类都有唯一的类对象，具体到本例，就是唯一的ThreadTest3.class对象。不管我们创建了该类的多少实例，但是它的类实例仍然是一个！

转载注明出处：http://x- spirit.javaeye.com/、http: //www.blogjava.net/zhangwei217245/
这样我们就知道了：



1、对于同步的方法或者代码块来说，必须获得对象锁才能够进入同步方法或者代码块进行操作；

转载注明出处：http://x- spirit.javaeye.com/、http: //www.blogjava.net/zhangwei217245/
2、如果采用method级别的同步，则对象锁即为method所在的对象，如果是静态方法，对象锁即指method所在的
Class对象(唯一)；

转载注明出处：http://x- spirit.javaeye.com/、http: //www.blogjava.net/zhangwei217245/
3、对于代码块，对象锁即指synchronized(abc)中的abc；


4、因为第一种情况，对象锁即为每一个线程对象，因此有多个，所以同步失效，第二种共用同一个对象锁lock，因此同步生效，第三个因为是
static因此对象锁为ThreadTest3的class 对象，因此同步生效。

转载注明出处：http://x- spirit.javaeye.com/、http: //www.blogjava.net/zhangwei217245/
如上述正确，则同步有两种方式，同步块和同步方法（为什么没有wait和notify？这个我会在补充章节中做出阐述）

如果是同步代码块，则对象锁需要编程人员自己指定，一般有些代码为synchronized(this)只有在单态模式才生效；
（本类的实例有且只有一个）

如果是同步方法，则分静态和非静态两种。


静态方法则一定会同步，非静态方法需在单例模式才生效，推荐用静态方法(不用担心是否单例)。

转载注明出处：http://x- spirit.javaeye.com/、http: //www.blogjava.net/zhangwei217245/
所以说，在Java多线程编程中，最常见的synchronized关键字实际上是依靠对象锁的机制来实现线程同步的。
我们似乎可以听到synchronized在向我们说：“给我一把锁，我能创造一个规矩”。

 

们已经了解了Java多线程编程中常用的关键字synchronized，以及与之相关的对象锁机制。这一节中，让我们一起来认识JDK 5中新引入的并发框架中的锁机制。

我想很多购买了《Java程序员面试宝典》之类图书的朋友一定对下面这个面试题感到非常熟悉：

问：请对比synchronized与java.util.concurrent.locks.Lock 的异同。
答案：主要相同点：Lock能完成synchronized所实现的所有功能
     主要不同点：Lock有比synchronized更精确的线程语义和更好的性能。synchronized会自动释放锁，而Lock一定要求程序员手工释放，并且必须在finally从句中释放。

恩，让我们先鄙视一下应试教育。

言归正传，我们先来看一个多线程程序。它使用多个线程对一个Student对象进行访问，改变其中的变量值。我们首先用传统的synchronized 机制来实现它：

public   class  ThreadDemo  implements  Runnable {

     class  Student {

         private   int  age  =   0 ;

         public   int  getAge() {
             return  age;
        }

         public   void  setAge( int  age) {
             this .age  =  age;
        }
    }
    Student student  =   new  Student();
     int  count  =   0 ;

     public   static   void  main(String[] args) {
        ThreadDemo td  =   new  ThreadDemo();
        Thread t1  =   new  Thread(td,  " a " );
        Thread t2  =   new  Thread(td,  " b " );
        Thread t3  =   new  Thread(td,  " c " );
        t1.start();
        t2.start();
        t3.start();
    }

     public   void  run() {
        accessStudent();
    }

     public   void  accessStudent() {
        String currentThreadName  =  Thread.currentThread().getName();
        System.out.println(currentThreadName  +   "  is running! " );
         synchronized  ( this ) { // (1)使用同一个ThreadDemo对象作为同步锁
            System.out.println(currentThreadName  +   "  got lock1@Step1! " );
             try  {
                count ++ ;
                Thread.sleep( 5000 );
            }  catch  (Exception e) {
                e.printStackTrace();
            }  finally  {
                System.out.println(currentThreadName  +   "  first Reading count: "   +  count);
            }

        }
       
        System.out.println(currentThreadName  +   "  release lock1@Step1! " );

         synchronized  ( this ) { // (2)使用同一个ThreadDemo对象作为同步锁
            System.out.println(currentThreadName  +   "  got lock2@Step2! " );
             try  {
                Random random  =   new  Random();
                 int  age  =  random.nextInt( 100 );
                System.out.println( " thread  "   +  currentThreadName  +   "  set age to: "   +  age);

                 this .student.setAge(age);

                System.out.println( " thread  "   +  currentThreadName  +   "  first  read age is: "   +   this .student.getAge());

                Thread.sleep( 5000 );
            }  catch  (Exception ex) {
                ex.printStackTrace();
            }  finally {
                System.out.println( " thread  "   +  currentThreadName  +   "  second read age is: "   +   this .student.getAge());
            }

        }
        System.out.println(currentThreadName  +   "  release lock2@Step2! " );
    }
}

转载注明出处：http://x- spirit.javaeye.com/、http: //www.blogjava.net/zhangwei217245/
运行结果：

a is running!
a got lock1@Step1!
b is running!
c is running!
a first Reading count: 1
a release lock1@Step1!
a got lock2@Step2!
thread a set age to: 76
thread a first  read age is: 76
thread a second read age is: 76
a release lock2@Step2!
c got lock1@Step1!
c first Reading count: 2
c release lock1@Step1!
c got lock2@Step2!
thread c set age to: 35
thread c first  read age is: 35
thread c second read age is: 35
c release lock2@Step2!
b got lock1@Step1!
b first Reading count: 3
b release lock1@Step1!
b got lock2@Step2!
thread b set age to: 91
thread b first  read age is: 91
thread b second read age is: 91
b release lock2@Step2!
成功生成（总时间： 30  秒）

显然，在这个程序中，由于两段synchronized块使用了同样的对象做为对象锁，所以JVM优先使刚刚释放该锁的线程重新获得该锁。这样，每个线程执行的时间是10秒钟，并且要彻底把两个同步块的动作执行完毕，才能释放对象锁。这样，加起来一共是 30秒。
转载注明出处：http://x- spirit.javaeye.com/、http: //www.blogjava.net/zhangwei217245/
我想一定有人会说：如果两段synchronized块采用两个不同的对象锁，就可以提高程序的并发性，并且，这两个对象锁应该选择那些被所有线程所共享的对象。

那么好。我们把第二个同步块中的对象锁改为student（此处略去代码，读者自己修改），程序运行结果为：

a is running!
a got lock1@Step1!
b is running!
c is running!
a first Reading count: 1
a release lock1@Step1!
a got lock2@Step2!
thread a set age to: 73
thread a first  read age is: 73
c got lock1@Step1!
thread a second read age is: 73
a release lock2@Step2!
c first Reading count: 2
c release lock1@Step1!
c got lock2@Step2!
thread c set age to: 15
thread c first  read age is: 15
b got lock1@Step1!
thread c second read age is: 15
c release lock2@Step2!
b first Reading count: 3
b release lock1@Step1!
b got lock2@Step2!
thread b set age to: 19
thread b first  read age is: 19
thread b second read age is: 19
b release lock2@Step2!
成功生成（总时间： 21  秒）

从修改后的运行结果来看，显然，由于同步块的对象锁不同了，三个线程的执行顺序也发生了变化。在一个线程释放第一个同步块的同步锁之后，第二个线程就可以进入第一个同步块，而此时，第一个线程可以继续执行第二个同步块。这样，整个执行过程中，有10秒钟的时间是两个线程同时工作的。另外十秒钟分别是第一个线程执行第一个同步块的动作和最后一个线程执行第二个同步块的动作。相比较第一个例程，整个程序的运行时间节省了1/3。细心的读者不难总结出优化前后的执行时间比例公式：(n+1)/2n，其中n为线程数。如果线程数趋近于正无穷，则程序执行效率的提高会接近50%。而如果一个线程的执行阶段被分割成m个 synchronized块，并且每个同步块使用不同的对象锁，而同步块的执行时间恒定，则执行时间比例公式可以写作：((m- 1)n+1)/mn那么当m趋于无穷大时，线程数n趋近于无穷大，则程序执行效率的提升几乎可以达到100%。（显然，我们不能按照理想情况下的数学推导来给BOSS发报告，不过通过这样的数学推导，至少我们看到了提高多线程程序并发性的一种方案，而这种方案至少具备数学上的可行性理论支持。）
转载注明出处：http://x- spirit.javaeye.com/、http: //www.blogjava.net/zhangwei217245/
可见，使用不同的对象锁，在不同的同步块中完成任务，可以使性能大大提升。

很多人看到这不禁要问：这和新的Lock框架有什么关系？

别着急。我们这就来看一看。

synchronized块的确不错，但是他有一些功能性的限制：
1. 它无法中断一个正在等候获得锁的线程，也无法通过投票得到锁，如果不想等下去，也就没法得到锁。
2.synchronized 块对于锁的获得和释放是在相同的堆栈帧中进行的。多数情况下，这没问题（而且与异常处理交互得很好），但是，确实存在一些更适合使用非块结构锁定的情况。
转载注明出处：http://x- spirit.javaeye.com/、http: //www.blogjava.net/zhangwei217245/
java.util.concurrent.lock 中的 Lock 框架是锁定的一个抽象，它允许把锁定的实现作为 Java 类，而不是作为语言的特性来实现。这就为 Lock 的多种实现留下了空间，各种实现可能有不同的调度算法、性能特性或者锁定语义。

JDK 官方文档中提到：
ReentrantLock是“一个可重入的互斥锁 Lock，它具有与使用 synchronized  方法和语句所访问的隐式监视器锁相同的一些基本行为和语义，但功能更强大。
ReentrantLock 将由最近成功获得锁，并且还没有释放该锁的线程所拥有。当锁没有被另一个线程所拥有时，调用 lock 的线程将成功获取该锁并返回。如果当前线程已经拥有该锁，此方法将立即返回。可以使用 isHeldByCurrentThread() 和 getHoldCount() 方法来检查此情况是否发生。 ”

简单来说，ReentrantLock有一个与锁相关的获取计数器，如果拥有锁的某个线程再次得到锁，那么获取计数器就加1，然后锁需要被释放两次才能获得真正释放。这模仿了 synchronized 的语义；如果线程进入由线程已经拥有的监控器保护的 synchronized 块，就允许线程继续进行，当线程退出第二个（或者后续） synchronized 块的时候，不释放锁，只有线程退出它进入的监控器保护的第一个 synchronized 块时，才释放锁。
转载注明出处：http://x- spirit.javaeye.com/、http: //www.blogjava.net/zhangwei217245/
ReentrantLock  类（重入锁）实现了 Lock ，它拥有与 synchronized 相同的并发性和内存语义，但是添加了类似锁投票、定时锁等候和可中断锁等候的一些特性。此外，它还提供了在激烈争用情况下更佳的性能。（换句话说，当许多线程都想访问共享资源时，JVM 可以花更少的时候来调度线程，把更多时间用在执行线程上。）

我们把上面的例程改造一下：

public   class  ThreadDemo  implements  Runnable {

     class  Student {

         private   int  age  =   0 ;

         public   int  getAge() {
             return  age;
        }

         public   void  setAge( int  age) {
             this .age  =  age;
        }
    }
    Student student  =   new  Student();
     int  count  =   0 ;
    ReentrantLock lock1  = new ReentrantLock(false);
    ReentrantLock lock2 = new ReentrantLock(false );

     public   static   void  main(String[] args) {
        ThreadDemo td  =   new  ThreadDemo();
         for  ( int  i  =   1 ; i  <=   3 ; i ++ ) {
            Thread t  =   new  Thread(td, i  +   "" );
            t.start();
        }
    }

     public   void  run() {
        accessStudent();
    }

     public   void  accessStudent() {
        String currentThreadName  =  Thread.currentThread().getName();
        System.out.println(currentThreadName  +   "  is running! " );
        lock1.lock(); // 使用重入锁
        System.out.println(currentThreadName  +   "  got lock1@Step1! " );
         try  {
            count ++ ;
            Thread.sleep( 5000 );
        }  catch  (Exception e) {
            e.printStackTrace();
        }  finally  {
            System.out.println(currentThreadName  +   "  first Reading count: "   +  count);
            lock1.unlock();
            System.out.println(currentThreadName  +   "  release lock1@Step1! " );
        }

        lock2.lock(); // 使用另外一个不同的重入锁
        System.out.println(currentThreadName  +   "  got lock2@Step2! " );
         try  {
            Random random  =   new  Random();
             int  age  =  random.nextInt( 100 );
            System.out.println( " thread  "   +  currentThreadName  +   "  set age to: "   +  age);

             this .student.setAge(age);

            System.out.println( " thread  "   +  currentThreadName  +   "  first  read age is: "   +   this .student.getAge());

            Thread.sleep( 5000 );
        }  catch  (Exception ex) {
            ex.printStackTrace();
        }  finally  {
            System.out.println( " thread  "   +  currentThreadName  +   "  second read age is: "   +   this .student.getAge());
            lock2.unlock();
            System.out.println(currentThreadName  +   "  release lock2@Step2! " );
        }

    }
}

从上面这个程序我们看到：

对象锁的获得和释放是由手工编码完成的，所以获得锁和释放锁的时机比使用同步块具有更好的可定制性。并且通过程序的运行结果（运行结果忽略，请读者根据例程自行观察），我们可以发现，和使用同步块的版本相比，结果是相同的。
转载注明出处：http://x- spirit.javaeye.com/、http: //www.blogjava.net/zhangwei217245/
这说明两点问题：
1. 新的ReentrantLock的确实现了和同步块相同的语义功能。而对象锁的获得和释放都可以由编码人员自行掌握。
2. 使用新的ReentrantLock，免去了为同步块放置合适的对象锁所要进行的考量。
3. 使用新的ReentrantLock，最佳的实践就是结合try/finally块来进行。在try块之前使用lock方法，而在finally中使用unlock方法。
转载注明出处：http://x- spirit.javaeye.com/、http: //www.blogjava.net/zhangwei217245/
细心的读者又发现了：

在我们的例程中，创建ReentrantLock实例的时候，我们的构造函数里面传递的参数是false。那么如果传递 true又回是什么结果呢？这里面又有什么奥秘呢？

 

首先，ReentrantLock有一个带布尔型参数的构造函数，在JDK官方文档中对它是这样描述的：
“此类的构造方法接受一个可选的公平 参数。当设置为 true 时，在多个线程的争用下，这些锁倾向于将访问权授予等待时间最长的线程。否则此锁将无法保证任何特定访问顺序。与采用默认设置（使用不公平锁）相比，使用公平锁的程序在许多线程访问时表现为很低的总体吞吐量（即速度很慢，常常极其慢），但是在获得锁和保证锁分配的均衡性时差异较小。不过要注意的是，公平锁不能保证线程调度的公平性。因此，使用公平锁的众多线程中的一员可能获得多倍的成功机会，这种情况发生在其他活动线程没有被处理并且目前并未持有锁时。还要注意的是，未定时的 tryLock  方法并没有使用公平设置。因为即使其他线程正在等待，只要该锁是可用的，此方法就可以获得成功。 ”

简单来讲：公平锁使线程按照请求锁的顺序依次获得锁；而不公平锁则允许讨价还价，在这种情况下，线程有时可以比先请求锁的其他线程先得到锁。

观察采用公平锁和非公平锁的例程运行效果发现：线程获得锁的顺序发生了一些变化(见下表)。

Unfair:   1 is running! 1 got lock1@Step1! 3 is running! 2 is running! 1 first Reading count:1 1 release lock1@Step1! 3 got lock1@Step1! 1 got lock2@Step2! thread 1 set age to:18 thread 1 first read age is:18 3 first Reading count:2 3 release lock1@Step1! 2 got lock1@Step1! thread 1 second read age is:18 1 release lock2@Step2! 3 got lock2@Step2! thread 3 set age to:34 thread 3 first read age is:34 2 first Reading count:3 2 release lock1@Step1! thread 3 second read age is:34 3 release lock2@Step2! 2 got lock2@Step2! thread 2 set age to:72 thread 2 first read age is:72 thread 2 second read age is:72 2 release lock2@Step2! 成功生成（总时间：20 秒）

Fair:   1 is running! 1 got lock1@Step1! 2 is running! 3 is running! 1 first Reading count:1 1 release lock1@Step1! 1 got lock2@Step2! thread 1 set age to:82 thread 1 first read age is:82 2 got lock1@Step1! 2 first Reading count:2 2 release lock1@Step1! 3 got lock1@Step1! thread 1 second read age is:82 1 release lock2@Step2! 2 got lock2@Step2! thread 2 set age to:65 thread 2 first read age is:65 3 first Reading count:3 3 release lock1@Step1! thread 2 second read age is:65 2 release lock2@Step2! 3 got lock2@Step2! thread 3 set age to:31 thread 3 first read age is:31 thread 3 second read age is:31 3 release lock2@Step2! 成功生成（总时间：20 秒）

转载注明出处：http://x- spirit.javaeye.com/、http: //www.blogjava.net/zhangwei217245/
这样的变化告诉我们：
采用非公平的锁时，当一个线程释放了第一个锁以后，由于线程的抢占，刚刚被释放的锁马上被下一个线程占有。采用公平锁时，由于公平锁倾向于将访问权授予等待时间最长的线程，所以，当第一个锁被第一个线程释放以后，第二个锁马上将访问权授予第一个线程，而第一个锁将访问权授予了第二个线程。这里，公平锁在平衡分配方面耗费了一定的时间，这使得第一个线程获得第二个锁的时间优先于第二个线程获得第一个锁。这样，采用不同的锁，就出现了两种不同的结果。
转载注明出处：http://x- spirit.javaeye.com/、http: //www.blogjava.net/zhangwei217245/
为了看到公平锁和非公平锁性能上的差异，我们不妨将其中线程的睡眠时间设定为1毫秒，然后把循环产生的线程数提高到5000（修改后的代码已忽略，自行修改），可以发现，由于公平锁要维持锁分配的均衡性，所以，采用公平锁的程序总运行时间更长一些。
转载注明出处：http://x- spirit.javaeye.com/、http: //www.blogjava.net/zhangwei217245/
根据运行环境的差异，有些朋友可能并不一定能很直观的从运行结果中看到两种不同的锁带来的性能差异。不妨引用IBM开发者社区的一组测试结果来看一看就行有什么样的差异吧：
4CPU情况下的同步、非公平锁和公平锁吞吐量比较：

单CPU情况下，同步、非公平锁和公平锁的吞吐量：


可以看到，同步和公平锁的吞吐量都是最低的，公平锁更低一些。但是同步内置的监控器锁是不公平的，而且永远都是不公平的。而JVM 保证了所有线程最终都会得到它们所等候的锁。确保统计上的公平性，对多数情况来说，这就已经足够了，而这花费的成本则要比绝对的公平保证的低得多。
转载注明出处：http://x- spirit.javaeye.com/、http: //www.blogjava.net/zhangwei217245/
既然Lock这么近乎完美，那我们也许可以忘却synchronized了。

但是任何事物都是有两面性的。
1.使用Lock，你必须手动的在finally块中释放锁。锁的获得和释放是不受JVM控制的。这要求编程人员更加细心。
2.当 JVM 用 synchronized 管理锁定请求和释放时，JVM 在生成线程转储时能够包括锁定信息。这些对调试非常有价值，因为它们能标识死锁或者其他异常行为的来源。 Lock 类只是普通的类，JVM 不知道具体哪个线程拥有 Lock 对象。
转载注明出处：http://x- spirit.javaeye.com/、http: //www.blogjava.net/zhangwei217245/
Lock提供了在多线程争用的情况下更好的并发性，但这是以牺牲一定的可维护性为代价的。
转载注明出处：http://x- spirit.javaeye.com/、http: //www.blogjava.net/zhangwei217245/
所以说，当大量线程发生争用的时候，Lock来了，大家都让开。