可见性

可见性（visibility）的问题是Java多线程应用中的错误的根源。在一个单线程程序中，如果首先改变一个变量的值，再读取该变量的值的时候，所读取到的值就是上次写操作写入的值。也就是说前面操作的结果对后面的操作是肯定可见的。但是在多线程程序中，如果不使用一定的同步机制，就不能保证一个线程所写入的值对另外一个线程是可见的。造成这种情况的原因可能有下面几个：

• CPU 内部的缓存：现在的CPU一般都拥有层次结构的几级缓存。CPU直接操作的是缓存中的数据，并在需要的时候把缓存中的数据与主存进行同步。因此在某些时刻，缓存中的数据与主存内的数据可能是不一致的。某个线程所执行的写入操作的新值可能当前还保存在CPU的缓存中，还没有被写回到主存中。这个时候，另外一个线程的读取操作读取的就还是主存中的旧值。

• CPU的指令执行顺序：在某些时候，CPU可能改变指令的执行顺序。这有可能导致一个线程过早的看到另外一个线程的写入操作完成之后的新值。

• 编译器代码重排：出于性能优化的目的，编译器可能在编译的时候对生成的目标代码进行重新排列。

现实的情况是：不同的CPU可能采用不同的架构，而这样的问题在多核处理器和多处理器系统中变得尤其复杂。而Java的目标是要实现“编写一次，到处运行”，因此就有必要对Java程序访问和操作主存的方式做出规范，以保证同样的程序在不同的CPU架构上的运行结果是一致的。Java内存模型（Java Memory Model）就是为了这个目的而引入的。JSR 133则进一步修正了之前的内存模型中存在的问题。总得来说，Java内存模型描述了程序中共享变量的关系以及在主存中写入和读取这些变量值的底层细节。Java内存模型定义了Java语言中的synchronized、volatile和final等关键词对主存中变量读写操作的意义。Java开发人员使用这些关键词来描述程序所期望的行为，而编译器和JVM负责保证生成的代码在运行时刻的行为符合内存模型的描述。比如对声明为volatile的变量来说，在读取之前，JVM会确保CPU中缓存的值首先会失效，重新从主存中进行读取；而写入之后，新的值会被马上写入到主存中。而synchronized和volatile关键词也会对编译器优化时候的代码重排带来额外的限制。比如编译器不能把 synchronized块中的代码移出来。对volatile变量的读写操作是不能与其它读写操作一块重新排列的。

Java中的锁

当数据竞争存在的时候，最简单的解决办法就是加锁。锁机制限制在同一时间只允许一个线程访问产生竞争的数据的临界区。Java语言中的 synchronized关键字可以为一个代码块或是方法进行加锁。任何Java对象都有一个自己的监视器，可以进行加锁和解锁操作。当受到 synchronized关键字保护的代码块或方法被执行的时候，就说明当前线程已经成功的获取了对象的监视器上的锁。当代码块或是方法正常执行完成或是发生异常退出的时候，当前线程所获取的锁会被自动释放。一个线程可以在一个Java对象上加多次锁。同时JVM保证了在获取锁之前和释放锁之后，变量的值是与主存中的内容同步的。

Java线程的同步

在有些情况下，仅依靠线程之间对数据的互斥访问是不够的。有些线程之间存在协作关系，需要按照一定的协议来协同完成某项任务，比如典型的生产者-消费者模式。这种情况下就需要用到Java提供的线程之间的等待-通知机制。当线程所要求的条件不满足时，就进入等待状态；而另外的线程则负责在合适的时机发出通知来唤醒等待中的线程。Java中的java.lang.Object类中的wait/notify/notifyAll方法组就是完成线程之间的同步的。

在某个Java对象上面调用wait方法的时候，首先要检查当前线程是否获取到了这个对象上的锁。如果没有的话，就会直接抛出java.lang.IllegalMonitorStateException异常。如果有锁的话，就把当前线程添加到对象的等待集合中，并释放其所拥有的锁。当前线程被阻塞，无法继续执行，直到被从对象的等待集合中移除。引起某个线程从对象的等待集合中移除的原因有很多：对象上的notify方法被调用时，该线程被选中；对象上的notifyAll方法被调用；线程被中断；对于有超时限制的wait操作，当超过时间限制时；JVM内部实现在非正常情况下的操作。

从上面的说明中，可以得到几条结论：wait/notify/notifyAll操作需要放在synchronized代码块或方法中，这样才能保证在执行 wait/notify/notifyAll的时候，当前线程已经获得了所需要的锁。当对于某个对象的等待集合中的线程数目没有把握的时候，最好使用 notifyAll而不是notify。notifyAll虽然会导致线程在没有必要的情况下被唤醒而产生性能影响，但是在使用上更加简单一些。由于线程可能在非正常情况下被意外唤醒，一般需要把wait操作放在一个循环中，并检查所要求的逻辑条件是否满足。典型的使用模式如下所示：

private Object lock = new Object();
synchronized (lock) { while (/* 逻辑条件不满足的时候 */) { try { lock.wait();  } catch (InterruptedException e) {} } //处理逻辑
}

中断线程

通过一个线程对象的interrupt()方法可以向该线程发出一个中断请求。中断请求是一种线程之间的协作方式。当线程A通过调用线程B的interrupt()方法来发出中断请求的时候，线程A 是在请求线程B的注意。线程B应该在方便的时候来处理这个中断请求，当然这不是必须的。当中断发生的时候，线程对象中会有一个标记来记录当前的中断状态。通过isInterrupted()方法可以判断是否有中断请求发生。如果当中断请求发生的时候，线程正处于阻塞状态，那么这个中断请求会导致该线程退出阻塞状态。可能造成线程处于阻塞状态的情况有：当线程通过调用wait()方法进入一个对象的等待集合中，或是通过sleep()方法来暂时休眠，或是通过join()方法来等待另外一个线程完成的时候。在线程阻塞的情况下，当中断发生的时候，会抛出java.lang.InterruptedException，代码会进入相应的异常处理逻辑之中。实际上在调用wait/sleep/join方法的时候，是必须捕获这个异常的。中断一个正在某个对象的等待集合中的线程，会使得这个线程从等待集合中被移除，使得它可以在再次获得锁之后，继续执行java.lang.InterruptedException异常的处理逻辑。

通过中断线程可以实现可取消的任务。在任务的执行过程中可以定期检查当前线程的中断标记，如果线程收到了中断请求，那么就可以终止这个任务的执行。当遇到 java.lang.InterruptedException的异常，不要捕获了之后不做任何处理。如果不想在这个层次上处理这个异常，就把异常重新抛出。当一个在阻塞状态的线程被中断并且抛出java.lang.InterruptedException异常的时候，其对象中的中断状态标记会被清空。如果捕获了java.lang.InterruptedException异常但是又不能重新抛出的话，需要通过再次调用interrupt()方法来重新设置这个标记。