线程开始运行,拥有自己的的栈空间,就如同一个脚本一样,按照既定的代码一步一步地执行,直到终止。但是,每个运行中的线程,如果仅仅是孤立的运行,那么没有一点儿价值,或者说价值很少。如果多个线程能够相互配合完成工作,这将会带来巨大的价值。
volatile 和 synchronized 关键字
Java 支持多个线程同时访问一个对象或者对象的成员变量,由于每个线程可以拥有这个变量的拷贝(虽然对象以及成员变量分配的内存是在共享内存中的,但是每个执行的线程还是可以拥有一份拷贝,这样做的目的是加速程序的执行,这是现代多核处理器的一个显著特性),所以程序在执行过程中,一个线程看到的变量并不一定是最新的。
volatile
关键字volatile可以用来修饰字段(成员变量),就是告知程序任何对该变量的访问均需要从共享内存中获取,而对它的改变必须同步刷新回共享内存,它能保证所有线程对变量访问的可见性。 举个例子,定义一个表示程序是否运行的成员变量boolean on = true,那么另一个线程可能对它执行关闭动作(on = false),这里涉及多个线程对变量的访问,因此需要将其定义成为volatile boolean on = true,这样其他线程对它进行改变时,可以让所有线程感知到变化,因为所有对on变量的访问和修改都需要以共享内存为准。但是,过多的使用volatile 是不惜要的,因为它会降低程序执行的效率
synchronized
关键字synchronized可以修饰方法或者以同步块的形式来进行使用,它主要确保多个线程在同一时刻,只能有一个线程处于方法或者同步块中,它保证了线程对变量访问的可见性和排他性。 在如下代码清单中,使用了同步块和同步方法,通过使用javap工具查看生成的class文件信息来分析synchronized关键字的实现细节
public class synchronized{
public static void main(String[] args){
// 对synchronized class 对象进行加锁
synchronized (Synchronized.class){
}
//静态同步方法,对Synchronized Class对象进行枷锁
m();
}
public static synchronized void m(){
};
}
复制代码
在Synchronized.class 统计目录执行javap-v Synchronized.class 部分相关输出如下所示:
public static void main(java.lang.String[]);
//方法修饰符,表示:public staticflags: ACC_PUBLIC, ACC_STATIC
Code:
stack=2, locals=1, args_size=1
0:1dc #1 //class com/murdock/books/multithread/book/Synchronized
2: dup
3: monitorenter //monitorenter:监视器进入,获取锁
4: monitorenter //monitorexit:监视器退出,释放锁
5: invokestatic #16 //Method m:V
8: return
public static synchronized void m();
//方法修饰符,表示:public static synchronized
flags: ACC_PUBLIC, ACC_STATIC, ACC_SYNCHRONIZED
Code:
stack=0,locals=0,args_size=0
0: return
复制代码
上面class信息中,对于同步快的实现使用了monitorenter和monitorexit指令,而同步方法则是依靠方法修饰符上的ACC_SYNCHRONIZED 来完成的。无论采用哪种方式,其本质是对一个对象的监视器(monitor)进行获取,而这个获取是排他的,也就是同一时刻只能有一个线程获取到有synchronized所保护对象的监视器。 任意一个对象都拥有自己的监视器,当这个对象由同步块或者这个对象的同步方法调用时,执行方法的线程必须先获取到该对象的监视器才能进入同步块或者同步方法,而没有获取到监视器(执行该方法)的线程将会被阻塞在同步块和同步方法的入口处,进入BLOCKED状态。
图1-1 对象、监视器、同步队列和执行线程之间的关系如图1-1可以看出,任意线程对Object(Object 由synchronized保护)的访问,首先要获得Object的监视器。如果获取失败,线程进入同步队列,线程状态变为BLOCKED。当访问Object的前驱(获得了锁的线程)释放了锁,则该释放锁操作唤醒阻塞在同步队列中的线程,使其重新尝试对监视器的获取。
等待/通知机制
一个线程修改了一个对象的值,而另一个线程感知到了变化,然后进行相应的操作,整个过程开始于一个线程,而最终执行又是另一个线程。前者是生产者,后者是消费者,这种模式隔离了“做什么(what)和怎么做(How)”,在功能层面上实现了解耦,体系结构上具备了良好的伸缩性,但是在Java语言中如何实现类似的功能呢?
简单的办法是让消费者线程不断的循环检查变量是否符合预期,如下面代码所示,在while循环中设置不满足的条件,如果条件满足则退出while循环,从而完成消费者的工作
while (value != desire){
Thread.sleep(1000);
}
doSomething();
复制代码
上面这段伪代码在条件不满足时就睡眠一段时间,这样做的目的是防止过快的“无效”尝试,这总方式看似能够解实现所需的功能,但是却存在如下问题。
- 难以确保及时性。在睡眠时,基本不消耗处理器资源,但是如果睡得过久,就不能及时发现条件已经变化,也就是及时性难以保证。
- 难以减低开销。如果降低睡眠的时间,比如休闲1毫秒,这样消费者能更加迅速地发现条件变化,但是却可能消耗更多的处理器资源,造成了无端的浪费。
以上两个问题,看似矛盾难以调和,但是Java通过内置的等待/通知机制能够很好的解决这个矛盾并实现所需的功能。
等待/通知的相关方法是任意Java对象都是具备的,因为这些方法被定义在所有对象的超类java.lang.Object 方法和描述如下表所示:
方法名称 | 描述 |
---|---|
notify() | 通知一个在对象上等待的线程,使其从wait()方法返回,而返回的前提是该线程获取到了对象的锁 |
notifyAll() | 通知所有等待在该对象上的线程 |
wait() | 调用该方法的线程进入WAITING状态,只有等待另外线程的通知或被中断才会返回,需要注意,调用wait()方法后,会释放对象的锁 |
wait(long) | 超时等待一段时间,这里的参数时间是毫秒,也就是等待长达n毫秒,如果没有通知就超时返回 |
wait(long,int) | 对于超时时间更细粒度的控制,可以达到纳秒 |
等待/通知机制,是指一个线程A调用了对象O的wait()方法进入等待状态,而另一个线程B调用了对象O的notify()或者notifyAll()方法,线程A收到通知后从对象O的wait()方法返回,进而执行后续操作。上述两个线程通过对象O来完成交互,而对象上的wait()和notify()/notifyAll()的关系就如同开关信号一样,用来完成等待方和通知方之间的交互工作
如下代码,创建了两个线程 WaitTHread 和 NotifyThread,前者检查flag值是否为false。如果符合要求,进行后续操作,否则在lock上等待,后者在睡眠了一段时间后对lock进行通知,示例如下:
public class WaitNotify{
static boolean flag = true;
static Object lock = new Object();;
public static void main(String[] args) throws Exception{
Thread waitThread = new Thread(new Wait(),"WaitThread");
waitThread.start();
TimeUnit.SECONDS.sleep(1);
Thread notifyThread = new Thread(new Notify(),"NotifyThread");
notifyThread.start();
}
static class Wait implements Runnable{
public void run{
//加锁,拥有lock的Monitor
synchronized(lock){
//当条件不满足时,继续wait,同时释放了lock的锁
while(flag){
System.out.println(Thread.currentThread()+"flag is true,wait@"+new SimpleDateFormat("HH:mm:ss").format(new Date()));
lock.wait();
}
}
//条件满足时,完成工作
System.out.pringln(Thread.currentThread()+"flag is false. running@"+new SimpleDateFormat("HH:mm:ss").format(new Date()));
}
}
static class Notify implements Runnable{
public void run(){
//加锁,拥有lock的Monitor
synchronized(lock){
//获取lock的锁,然后进行通知,通知时不会释放lock的锁
//知道当前线程释放了lock后,WaitThread才能从wait方法中返回
System.out.pringln(Thread.currentThread()+" hold lock.notify@"+new SimpleDateFormat("HH:mm:ss").format(new Date()));
lock.notifyAll();
SleepUtils.second(5);
}
synchronized(lock){
System.out.println(Thread.currentThread()+"hold lock again. sleep@"+new SimpleDateFormat("HH:mm:ss").format(new Data()));
}
}
}
}
复制代码
输出如下:(输出内容可能不容,主要去呗在时间上)
1.Thread[WaitThread,5,main] flag is true.wait @ 17:12:03
2.Thread[NotifyThread,5,main] hold lock.notify @ 17:12:04
3.Thread[NotifyThread,5,main] hold lock again. sleep @ 17:12:05
4.Thread[WaitThread,5,main] flag is false. running @ 17:12:06
复制代码
上述第三行和第四行输出的顺序可能会互换,而上述例子主要说明了调用wait()、norify()、以及notifyAll() 时需要注意的细节,如下:
- 使用wait()、notify()、和notifyAll()时需要先对调用对象加锁
- 调用wait()方法后,线程状态有RUNNING变为WAITING,并将当前线程放置到对象的等待队列
- notify() 或 notifyAll() 方法调用后,等待线程依旧不会从wait()返回,需要调用notify()或者notifyAll()的线程释放锁之后,等待线程才有机会从wait()返回
- notify()方法将等待队列中的一个等待线程从等待队列中移动到同步队列中,而notifyAll()方法则是将等待队列中所有的线程全部移到同步队列,被移动的线程状态由WAITING变为BLOCKED.
- 从wait()方法返回的前提是获得了调用对象的锁
从上述细节中可以看到,等待/通知机制依托于同步机制,其目的就是确保等待线程从wait()方法返回时能够感知到线程对变量做出的修改
如上图所示,WaitThread首先获取了对象的锁,然后调用对象的wait()方法,从而放弃了锁并进入了对象的等待队列WaitQueue中,进入等待状态。由于WaitThread释放了对象的锁,NotifyThread随后获取了对象的锁,并调用对象的Notify()方法,将WaitThread从WaitQueue移到SynchronizedQueue中,此时WaitThread的状态变为阻塞状态。 NotifyThread释放了锁之后,WaitThread再次获取到锁并从wait()返回继续执行。注意:只要同步队列内等待的线程未获取到对象锁,该(等待)线程始终未从wait()方法返回
生产经典模式
以上示例中可以提炼出等待/通知的经典范式,该范式分为两部分,分别针对等待方(消费者)和通知方(生产者) 等待方遵循如下原则。
- 获取对象的锁
- 如果条件不满足,那么调用对象的wait()方法,被通知后仍要检查条件
- 条件满足则执行对应的逻辑。 对应的伪代码如下: synchronized(对象){ while(条件不满足){ 对象.wait(); } 对应的处理逻辑 }
通知方遵循如下原则
- 获得对象的锁
- 改变条件
- 通知所有等待在对象上的线程 对应的伪代码如下: synchronized(对象){ 改变条件 对象.notifyAll(); }