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的例子：某餐厅的卫生间很小，几乎只能容纳一个人如厕。为了保证不受干扰，如厕的人进入卫生间，就要锁上房门。我们可以把卫生间想象成是共享的资源，而众多需要如厕的人可以被视作多个线程。假如卫生间当前有人占用，那么其他人必须等待，直到这个人如厕完毕，打开房门走出来为止。这就好比多个线程共享一个资源的时候，是一定要分出先来后到的。

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

正是因为有这道门，任何一个单独进入如厕的人都可以顺利的完成他们的如厕过程，而不会被干扰，甚至发生以外的结果。这就是说，如厕的时候要讲究先来后到。

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

卫生间的门。其实，卫生间的门担任的是资源锁的角色，只要如厕的人锁上门，就相当于获得了这个锁，而当他打开锁出来以后，就相当于释放了这个锁。

也就是说，多线程的线程同步机制实际上是靠锁的概念来控制的。那么在Java程序当中，锁是如何体现的呢？

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

在Java程序运行时环境中，JVM需要对两类线程共享的数据进行协调：

1）保存在堆中的实例变量

2）保存在方法区中的类变量

这两类数据是被所有线程共享的。

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

在java虚拟机中，每个对象和类在逻辑上都是和一个监视器相关联的。

对于对象来说，相关联的监视器保护对象的实例变量。

对于类来说，监视器保护类的类变量。

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

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

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

类锁实际上用对象锁来实现。当虚拟机装载一个class文件的时候，它就会创建一个https://www.360docs.net/doc/b213853445.html,ng.Class类的实例。当锁住一个对象的时候，实际上锁住的是那个类的Class对象。

一个线程可以多次对同一个对象上锁。对于每一个对象，java虚拟机维护一个加锁计数器，线程每获得一次该对象，计数器就加1，每释放一次，计数器就减1，当计数器值为0时，锁就被完全释放了。

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

在java程序中，只需要使用synchronized块或者synchronized方法就可以标志一个监视区域。当每次进入一个监视区域时，java虚拟机都会自动锁上对象或者类。

看到这里，我想你们一定都疲劳了吧？o(∩_∩)o...哈哈。让我们休息一下，但是在这之前，请你们一定要记着：

当一个有限的资源被多个线程共享的时候，为了保证对共享资源的互斥访问，我们一定要给他们排出一个先来后到。而要做到这一点，对象锁在这里起着非常重要的作用。

如果你想知道更多细节，请接着看本系列的第二篇吧。

在上一篇中，我们讲到了多线程是如何处理共享资源的，以及保证他们对资源进行互斥访问所依赖的重要机制：对象锁。

本篇中，我们来看一看传统的同步实现方式以及这背

后的原理。

很多人都知道，在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类的一个具体对象，也就是该线程自身作为对象锁的。一共十个线程，每个线程持有自己线程对象的那个对象锁。这必然不能产生同步的效果。换句话说，如果要对这些线程进行同步，那么这些线程所持有的对象锁应当是共享且唯一的！

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变量的区域。

程序将原来run方法前的synchronized关键字去掉，换用了run方法中的一个synchronized块来实现。这个同步块的对象锁，就是 main 方法中创建的那个String对象。换句话说，他们指向的是同一个String类型的对象，对象锁是共享且唯一的！

于是，我们看到了预期的效果：10个线程不再是争先恐后的报数了，而是一个接一个的报数。

再来看下面的例程：

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静态方法是用什么来做对象锁的呢？

我们知道，对于同步静态方法，对象锁就是该静态放发所在的类的Class实例，由于在JVM中，所有被加载的类都有唯一的类对象，具体到本例，就是唯一的ThreadTest3.class对象。不管我们创建了该类的多少实例，但是它的类实例仍然是一个！

这样我们就知道了：

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

2、如果采用method级别的同步，则对象锁即为method所在的对象，如果是静态方法，对象锁即指method所在的

Class对象(唯一)；

3、对于代码块，对象锁即指synchronized(abc)中的abc；

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

static因此对象锁为ThreadTest3的class 对象，因此同步生效。

如上述正确，则同步有两种方式，同步块和同步方法（为什么没有wait和notify？这个我会在补充章节中做出阐述）

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

（本类的实例有且只有一个）

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

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

所以说，在Java多线程编程中，最常见的synchronized关键字实际上是依靠对象锁的机制来实现线程同步的。

我们似乎可以听到synchronized在向我们说：“给我一把锁，我能创造一个规矩”。

下一篇中，我们将看到JDK 5提供的新的同步机制，也就是大名鼎鼎的Doug Lee提供的Java Concurrency框架。
在上一节中，我们已经了解了Java多线程编程中常用的关键字synchronized，以及与之相关的对象锁机制。这一节中，让我们一起来认识JDK 5中新引入的并发框架中的锁机制。

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

问：请对比synchronized与java.util.concurrent.locks.Lock 的异同。

答案：主要相同点：Lock能完成synchronized所实现的所有功能

主要不同点：Lock有比synchronized更精确的线程语义和更好的性能。synchronized会自动释放锁，而Lock一定要求程序员手工释放，并且必须在finally从句中释放。

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

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

public　class　ThreadDemo　implemen

ts　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　+　"　fi

rst 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!");
}
}

运行结果：

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秒。

我想一定有人会说：如果两段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　a

ge　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发报告，不过通过这样的数学推导，至少我们看到了提高多线程程序并发性的一种方案，而这种方案至少具备数学上的可行性理论支持。）

可见，使用不同的对象锁，在不同的同步块中完成任务，可以使性能大大提升。

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

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

synchronized块的确不错，但是他有一些功能性的限制：

1. 它无法中断一个正在等候获得锁的线程，也无法通过投票得到锁，如果不想等下去，也就没法得到锁。

2.synchronized 块对于锁的获得和释放是在相同的堆栈帧中进行的。多数情况下，这没问题（而且与异常处理交互得很好），但是，确实存在一些更适合使用非块结构锁定的情况。

java.util.concurrent.lock 中的 Lock 框架是锁定的一个抽象，它允许把锁定的实现作为 Java 类，而不是作为语言的特性来实现。这就为 Lock 的多种实现留下了空间，各种实现可能有不同的调度算法、性能特性或者锁定语义。

JDK 官方文档中提到：

ReentrantLock是“一个可重入的互斥锁 Lock，它具有与使用 synchronized 方法和语句所访问的隐式监视器锁相同的一些基本行为和语义，但功能更强大。

ReentrantLock 将由最近成功获得锁，并且还没有释放该锁的线程所拥有。当锁没有被另一个线程所拥有时，调用 lock 的线程将成功获取该锁并返回。如果当前线程已经拥有该锁，此方法将立即返回

。可以使用 isHeldByCurrentThread() 和 getHoldCount() 方法来检查此情况是否发生。 ”

简单来说，ReentrantLock有一个与锁相关的获取计数器，如果拥有锁的某个线程再次得到锁，那么获取计数器就加1，然后锁需要被释放两次才能获得真正释放。这模仿了 synchronized 的语义；如果线程进入由线程已经拥有的监控器保护的 synchronized 块，就允许线程继续进行，当线程退出第二个（或者后续） synchronized 块的时候，不释放锁，只有线程退出它进入的监控器保护的第一个 synchronized 块时，才释放锁。

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!");
}
}
}

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

对象锁的获得和释放是由手工编码完成的，所以获得锁和释放锁的时机比使用同步块具有更好的可定制性。并且通过程序的运行结果（运行结果忽略，请读者根据例程自行观察），我们可以发现，和使用同步块的版本相比，结果是相同的。

这说明两点问题：

1. 新的ReentrantLock的确实现了和同步块相同的语义功能。而对象锁的获得和释放都可以由编码人员自行掌握。

2. 使用新的ReentrantLock，免去了为同步块放置合适的对象锁所要进行的考量。

3. 使用新的ReentrantLock，最佳的实践就是结合try/finally块来进行。在try块之前使用lock方法，而在finally中使用unlock方法。

细心的读者又发现了：

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

请看本节的续 ———— Fair or Unfair? It is a question...

文章由北大青鸟.嘉华教育（深圳大学实训基地&北大青鸟全国三甲校区）：https://www.360docs.net/doc/b213853445.html, 深圳权威IT培训学校，欢迎课程咨询交流QQ：100236036。

本人亲自操作，简单，文章可以去我们网

站技术栏目：https://www.360docs.net/doc/b213853445.html,/tech/提取，祝你成功！