JAVA语言规范：线程和锁 1 同步
java编程语言提供了线程间通信的多种机制。这些方法中最基本的是同步化，此方法是使用监视器实现的。JAVA中每个对象与一个监视器相关联，一个线程可以加锁和解锁监视器。一次仅有一个线程可能在监视器上持有锁。尝试锁住该监视器的任何其他线程被阻塞，直到它们可以再该监视器上获得一个锁。线程 t可以多次锁住特别的监视器;每个解锁将一个加锁操作的作用反转来了。
synchronized语句计算了一个对象的引用;然后它尝试在该对象的监视器上执行加锁操作，并不进一步继续，直到锁操作已经成功完成。在加锁操作被执行完后，会执行synchronized语句体。如果语句体的执行没有完成(正常或突然)。那么将在相同的监视器上自动执行相同的解锁操作。
JAVA编程语言没有防止，也没有要求检查死锁条件。线程在多个对象上(直接或间接)持有锁的程序，应该使用传统技术来避免死锁，创建不会死锁的高级加锁原语(如果有必要的话)。其他机制(比如读写java.util.concurrent 包中的 volatile 变量和类)提供了一些同步的其他方法。
2 等待集合 和 通知
JAVA中的每个对象，都有一个关联的监视器，也会有一个关联的等待集合。等待集合是一个线程的集合。
当对象第一次被创建时，它的等待集合为空，增加或移除该集合中的线程，这样的简单操作都是原子性的。等待集合受到以下方法的操纵： Object.wait, Object.notify, and Object.notifyAll.。
等待集合的操作也受到线程中断状态的的影响，还有Thread类中那些可以进行中断线程方法的影响。此外在Thread类中的sleep和join的方法，它们能够获得等待集合和通知的动作。
2.1等待(Wait)
等待操作由wait()方法的执行引起，或者也可以由限定时间长度的wait()方法触发。
调用方法wait(long millisecs)或者函数wait(long millisecs, int nanosecs) ，当调用的参数均为0时，这样的调用等同于wait()。
如果线程在没有抛出InterruptedException 的情况下返回，那么线程就从wait 正常返回。
令线程t是在对象m上执行等待方法的线程，并令n是t在m上加锁操作的编号，这些操作已经不被解锁操作匹配。下面的操作之一发生：
如果n是0(也就是，线程t已经没有占用目标m的锁)则抛出IllegalMonitorStateException 异常。 如果这是一个定时等待，并且十亿分之一秒参数不在0-999999，或者毫秒参数是负的，那么就会抛出IllegalArgumentException 的异常。 如果线程t被中断，那就抛出InterruptedException，并将t的中断状态设置为假。
否则，下面的序列发生：
1、线程t被添加到对象m的等待集合中，并在m上执行n个解锁操作。
2、线程t没有执行任何的进一步指令，直到它已经从m的等待集合中删除。由于下面的操作的任何之一，该程序可能从等待集合中删除，并在后面的某个时间继续。
在等待等待集合中删除而选择的t的m上正在执行的notify操作。 在m上正被执行的notifyAll操作。 在t上执行的interrupt操作。 如果这是一个定时等待，则为m的等待集合删除的内部操作，该集合至少在millisecs毫秒加nanosecs十亿分之一秒消逝后发生(从写操作开始)。 根据实现的内部操作。实现被允许(尽管不鼓励)执行“伪造的唤醒”——以便从等待集合中删除中删除线程，从而能够在没有显式指令这样做的情况下再继续。注意这个装备成了在循环内使用wait的JAVA编码实践的必要条件，这些循环只有在线程等待持有的某个逻辑条件时才终止。
每个线程必须通过可能导致它从等待集合中删除的时间确定顺序。顺序不一定与其他的排序一直，但线程表现得像以那个循环发生的那些事件一样。
例如，如果线程t在m的等待队列中，然后t的中断和m的通知发生，那么在这些事件上必须有一个顺序。如果中断被认为首先发生，那么t将最终通过抛出 InterruptedException来从wait中中返回，而且中的等待集合的某个其他线程(如果在通知的时候存在的话)必须接收通知。如果通知被认为是首先发生的，那么t将最终正常地wait返回，且中断仍然挂起。
线程t在m上执行n个加锁操作。 如果由于中断线程t在步骤2中从m的等待集合中删除了，那么t的中断状态就被设置为假，并且等待方法抛出InterruptedException。
2.2 通知(notify)
通知操作在调用方法notify和notifyAll 调用之后发生。令线程t是执行对象m上的这些方法的任一方法的线程，并令n是t在m上的加锁操作的数量，这些操作没有被解锁操作匹配。下面操作之一发生了。
如果n是0，则抛出IllegalMonitorStateException。情形是这样的：线程t已经没有占有目标m的锁。 如果n大于0，并且这是一个notify操作，那么如果m的等待集合不是空的，则是m的当前等待集合的一个成员的线程u被选择，并从等待集合中删除(不保证在等待集合中选定哪个线程)。从等待集合中进行该删除让u在等待操作中得以继续。但注意，继续之后的u的加锁操作不能成功，直到t完全解锁m的监视器后的某个时间。 如果n大于0，并且这是一个notifyAll操作，那么所有的线程就从m的等待集合中删除并继续，但请注意。它们当中仅有的一个将一次锁住wait的继续期间需要的监视器 2.3 中断
中断操作在调用方法Thread.interrupt及定义来依次调用它的方法(比如ThreadGroup.interrupt)之后发生。对于某个线程u，令t是调用u.interrupt的线程，其中t和u可能是相同的。此操作导致u的中断状态被设置为真。
另外，如果存在着等待集合包含u的某个对象m，那么u就从m的等待集合中删除。这使得u能够在等待操作中继续，在该操作的情况中，此等待将在重新加锁m的监视器后抛出InterruptedException。
调用Thread.isInterrupted可以确定线程的中断状态。静态方法Thread.interrupted有线程调用来观察和清除自己的中断状态。
2.4 等待、通知和中断的交互
上面的规范允许我们确定于等待、通知和中断有关的几个属性。如果在等待时，线程同时是通知和中断的，它就可能是下面之一：
从wait正常返回，尽管仍然有挂起中断(在其他工作中，对Thread.interrupted的调用将返回真)。 通过抛出InterruptedException从wait处返回。
线程不可以重置它的中断状态，并从wait的调用中正常返回。
同样，通知不能由于中断而丢失。假定线程的集合s在对象m的等待集合中，并且另一个线程在m上执行notify，那么有下面之一发生：
至少s中有一个线程从wait处正常返回，或者 s中的所有线程必须通过抛出InterruptedException退出wait。
注意，如果线程通过notify被中断和唤醒，并且线程通过抛出InterruptedException从wait返回，那么等待集合中的某个线程必须被通知到。