线程安全

线程安全

当多个线程访问一个对象时，如果不用考虑这些线程在运行时环境下的调度和交替执行，也不需要进行额外的同步，或者在调用方进行任何其他的协调操作，调用这个对象的行为都可以获得正确的结果，那这个对象是线程安全的。

这个定义比较严谨，它要求线程安全的代码都必须具备一个特征：代码本身封装了所有必要的正确性保障手段（如互斥同步等），令调用者无须关心多线程问题，更无须自己才起任何措施来保证多线程的正确调用。

Java语言中的线程安全

按照线程安全的“安全程度”由强至弱来排序，我们可以将Java中各种操作共享的数据分为以下5类：不可变、绝对线程安全、相对线程安全、线程兼容、线程对立。

1.不可变

在Java中，不可变的对象一定是线程安全的，无论是对象的方法实现还是方法的调用者，都不需要再采取任何的线程安全保障措施，前面说过final关键字带来的可见性时曾经提过，只要一个不可变的对象被正确地构建出来（没有发生this引用逃逸），那其外部的可见状态永远也不会改变，永远也不会看到它在多个线程中处于不一致的状态。“不可变”带来的安全性是最简单和最纯粹的。

Java中如果共享数据是一个基本数据类型，那么只要在定义时使用final关键字修饰它就可以保证他是不可变的。如果共享数据是一个对象，那就需要保证对象的行为不会对其状态产生任何影响才行，如Stirng类的对象，它是一个典型的不可变对象，我们调用它的subString()、replace()和concat()这些方法都不会影响它原来的值，只会返回一个新构造的字符串对象。

保证对象行为不影响自己状态的途径有很多种，其中最简单的就是把对象中带有状态的变量都声明为final，这样在构造函数结束后，它就是不可变的，如下Integer构造函数，通过内部状态变量value定义为final来保证状态不变

在Java中符合不可变要求的类型，除了上面提到的String之外，常用的还有枚举类型，以及Number的部分子类，，如Long和Double等数值包装类型，BigIntger和BigDecimal等大数据类型；但同为Number的子类的原子类AtomicInteger和StomicLong则并非不可变的。可以看到value没有使用final修饰，而是使用volatile

2.绝对线程安全

绝对的线程安全完全满足上面的线程安全的定义，这个定义其实是很严格的，一个类要达到“不管运行时环境如何，调用者都不需要任何额外的同步措施”通常需要付出很大的，甚至有时候是不切实际的代价。在Java中标注自己是线程安全的类，大多数都不是绝对的线程安全。

例如java.util.Vector是一个线程安全的容器，因为它的add、get、size这类方法都是被synchronized修饰的，尽管这样效率很低，但确实是安全的。但是，即使它所有的方法都被修饰成同步，也不意味着调用它永远都不再需要同步手段了。

public class VectorTest {
   public static Vector<Integer> vector = new Vector<Integer>();
   public static void main(String[] args) {
         while (true){
         for (int i=0;i<10;i++){
            vector.add(i);
         }

         Thread removeThread = new Thread(new Runnable() {
            public void run() {
               for (int i=0;i<vector.size();i++){
                  vector.remove(i);
               }
            }
         });
         Thread printThread = new Thread(new Runnable() {
            public void run() {
               for (int i=0;i<vector.size();i++) {
                  System.out.println(vector.get(i));
               }
            }
         });
         removeThread.start();
         printThread.start();
      } 
     
   }
}

尽管这里使用到的vector个get、remove、size方法都是同步的，但是在多线程环境中，如果不在方法调用端做额外的同步措施，使用这段代码仍然是不安全的，因为如果另一个线程恰好在错误的时间里删除了一个元素，导致序号i已经不再可用的话，再用i访问数组就会抛出一个ArrayIndexOutOfBoundsException。如果要保证这段代码正常执行，不得不把removeThread和printThread定义改为：

Thread removeThread = new Thread(new Runnable() {
            public void run() {
               synchronized (vector){
                  for (int i=0;i<vector.size();i++){
                     vector.remove(i);
                  }
               }
            }
         });
         Thread printThread = new Thread(new Runnable() {
            public void run() {
               synchronized (vector){
                  for (int i=0;i<vector.size();i++) {
                     System.out.println(vector.get(i));
                  }
               }
            }
         });

3.相对线程安全

相对的线程安全就是我们通常意义上讲的线程安全，它需要保证对这个对象单独的操作时线程安全的，我们在调用时不需要做额外的保障措施，但是对于一些特定顺序的连续调用，就可能需要在调用端使用额外的同步手段来保证调用的正确性。在Java中，大部分线程安全类都属于这种类型，例如vector、hashTable、collections.synchronizedCollection方法包装的集合等。

4.线程兼容

线程兼容指对象本身不是线程安全，但是可以通过在调用端正确使用同步手段来保证对象在并发环境中可以安全使用，我们平时说一个类不是线程安全的，绝大多数时候指的是这一种情况。Java API中大部分的类属于线程兼容，如前面的Vector和hashtable相对应的集合类arraylist和hashmap等。

5.线程对立

线程对立是指无论调用端是否采用了同步措施，都无法在多线程中并发使用的代码。由于Java天生具备多线程特性，线程对立这种排斥多线程的代码时很少出现的，而且通常都是有害的，应当尽量避免。一个线程对立的例子是Thread类的suspend和resume方法，如果有两个线程同时持有一个线程对象，一个去尝试中断线程，另一个尝试去恢复线程，如果并发进行的话，吴润调用时是否进行了同步，目标线程都存在死锁的可能。如果suspend中断的线程就是即将要执行resume的那个线程，那就肯定死锁了。suspend和resume方法已经被JDK声明废弃了。

线程安全的实现方法

线程安全已与代码的编写关系密切，但虚拟机提供的同步和锁机制也起到了非常重要的作用。本节中，代码编写如何实现线程安全和虚拟机如何实现同步与锁这两者都会有所涉及。相对而言，更偏重后者一些，只要读者了解了JVM线程安全的运作手段，自己去思考代码如何编写并不是一件困难的事。

1.互斥同步

互斥同步是常见的一种并发正确性保障手段。同步是指多个线程并发访问共享数据时，保证共享数据在同一个时刻只被一个线程使用。互斥是实现同步的一种手段。

Java中最基本的互斥同步就是synchronized，synchronized编译后，会在同步块的前后分别形成monitorenter和monitorexit这两个字节码指令，这两个字节码都需要一个reference类型的参数来指明要锁定和解锁的对象。如果Java中synchronized明确指明了对象参数，那就是这个对象reference，如果没有明确指定，那就根据synchronized修饰的是实例方法还是类方法，去取对应的对象实例或class对象作为锁对象。

根据虚拟机规范要求，在执行monitorenter指令是，首先尝试获取对象的锁，如果这个对象没被锁定，或者当前线程已经拥有了那个对象的锁，把锁的计数器+1，相应的执行monitorexit指令时会将锁的计数器-1，当计数器为0时，锁就被释放。如果获取对象锁失败，那当前线程就要阻塞等待，直到对象锁被另一个线程释放为止。

注意两点：synchronized同步块对于同一条线程来说是可重入的，不会出现自己把自己锁死了。其次，同步块在已进入的线程执行完之前，会阻塞后面其他线程的进入。前面说过，Java的线程是映射到操作系统的原生线程上的，如果要阻塞或者唤醒一个线程，都需要操作系统来帮忙完成，这就需要从用户态装换到内核态中，因此状态转换需要耗费很多的处理器时间。对于代码简单的同步块（如被synchronized修饰的getter和setter方法），状态转换消耗的时间有可能比用户代码执行时间还长。所以synchronized是Java语言中一个重量级操作，虚拟机本身也会就行一些优化，譬如在通知操作系统堵塞线程之前加入一段自旋等待过程，避免频繁地切入到核心态中。

除了synchronized，我们还可以使用java.util.concurrent包中的重入锁来实现同步，在基本语法上reentrantLock与synchronized很相似，他们具备一样的线程重入特性，只是代码写法上有点区别，一个表现为API层面的互斥锁（lock和unlock方法配合try/finally语句块来完成），另一个表现为原生语法层面的互斥锁。不过，相比synchronized，reentrantLock增加了一些高级功能，主要由以下3项：等待可中断、可实现公平锁、以及锁可以绑定多个条件。

等待可中断是指当持有锁的线程长期不释放锁的时候，正在等待的线程可以选择放弃等待，改为处理其他事情，可中断特性对处理执行时间非常长的同步块很有帮助。

公平锁是指多个线程在等待同一个锁时，必须按照申请锁的时间顺序来依次获取锁，而非公平锁则不保证这一点，在锁被释放时，任何一个等待锁的线程都有机会获得锁。synchronized是非公平的，reetrantlock默认情况下也是非公平的，但可以通过带boolean值的构造函数要求使用公平锁。

如果需要使用到上述功能，选用reentrantlock是一个很好的选择。

JDK1.5之前多线程下的synchronized的吞吐量下降的非常严重，而reentrantlock则能基本保持在同一个比较稳定的水平下。与其说reentrantlock性能好，不如说synchronized还有很大的优化余地。1.6加入了很多针对锁的优化措施，1.6发布后，性能就差不多持平了。JVM在未来的性能改进中肯定更加偏向于synchronized，所以还是提倡在synchronzied能实现需求的情况下，优先使用synchronized同步。

2.非阻塞同步

互斥同步最主要的问题就是进行线程阻塞和唤醒带来的性能问题。因此这种同步也称为阻塞同步。互斥同步属于一种悲观的并发策略，总是认为只要不去做正确的同步措施（例如加锁），那就肯定会出现问题。用户态核心态转换、维护锁计数器检查是否有阻塞的线程需要唤醒等操作。随着硬件指令集发展，我们有了另一个选择：基于冲突检查的乐观并发策略。这种乐观锁的并发策略的许多实现都不需要把线程挂起，因此这种同步操作称为非阻塞同步。

为什么笔者说使用乐观并发策略需要“硬件指令集发展”才能进行呢？因为需要操作和冲突检测这两个步骤具备原子性。

通过CAS来实现非阻塞同步，CAS指令需要有3个操作数，内存位置V，旧的预期值A，新值B。CAS指令执行时，当且仅当V符合A时才用新值B更新V的值，否则它不执行更新，但是无论是否更新了V的值，都会返回V的旧值，上述操作是一个原子操作。

JDK1.5之后，Java程序中才可以使用CAS操作，该操作由sun.misc.Unsafe类中的compareAndSwapInt和compareAndSwapLong等几个方法包装提供，虚拟机内部对这些方法做了特殊处理，即时编译出来的结果就是一条平台相关的处理器CAS指令，没有方法调用的过程，或者可以认为无条件内联进去了。

由于unsafe类不是提供给用户程序调用的类（Unsafe.getUnsafe代码中限制了只有启动类加载器（bootstrap classloader）加载的class才能访问它），因此，如果不采用反射手段，我们只能通过其他的Java API来间接使用它，如JUC中整数原子类，其中的compareAndSet和getAndIncrement等方法都使用了Unsafe类的CAS操作。

3.无同步方案

要保证线程安全并不一定就要进行同步，两者没有因果关系。同步只是保证共享数据争用时的正确性的手段，如果一个方法本身就不涉及共享数据，那它自然就无需同步措施保证正确性，因此有一些代码天生线程安全，如可重入代码，线程本地存储、

可重入代码：不依赖存储在堆上的数据和公共系统资源，用到的状态量都由参数中传入，不调用非可重入的方法等。可以通过·一个简单的原则来判断代码是否具备可重入性：如果一个方法，它的返回结果是可以预测的，主要输入了相同的数据，就能返回相同的结果，那它就满足可重入性的要求，当然也就是线程安全的。