Java线程安全——深入理解Java虚拟机

 

什么是线程安全？

 

第一种比较常见但很鸡肋的说法是：如果一个对象可以安全的被多个线程同时使用，那它就是线程安全的。

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

 

 

一.Java语言中的线程安全

 

我们在这里不把线程安全看作一个非黑即白的概念，按照线程安全的“安全程度”有强到弱来排序，我们可以将Java语言中的各种操作共享的数据分为以下5类：不可变，绝对线程安全，线程兼容和线程对立。

 

• 不可变：永远也看不见某个对象在多个线程中处于不一致的状态。“不可变”带来的安全性是最简单和最纯粹的。Java语言中，如果共享的数据是一个基本类型的数据，那么只要在定义时使用final关键字修饰它就可以保证不变。如果共享的数据是一个对象，那就需要保证对象的行为不会对其状态产生任何影响才行，我们回忆一下Java.lang.String类的对象，它是一个典型的不可变对象，无论你调用它的substring(),raplace()等方法，都不会影响它原来的值，只会返回一个新构造的字符串对象。使对象称为无状态对象的方式有很多种，我们最长见的就是将对象中带有状态的变量声明为final，这样在构造函数结束之后，他就不可变可。

 

• 线程绝对安全：“不管运行环境如何，调用者都不需要任何额外的同步措施”，为了达到这种“绝对安全”的定义，常常需要符处很大的代价，甚至有时候使不切实际的代价。在Java API 中标准自己是线程安全的类，大多数都不是绝对线程安全的。

 

我们来举个例子吧！

 

Java.lang.Vector是一个线程安全的容器，因为它的能使实例状态发生改变的方法，比如add()，get()和size()这类方法都被synchronized修饰，尽管效率很低，但确实是线程安全的。但是，即使它的所有方法都被修饰称同步，也不意味着调用它的时候永远都不需要同步手段，看看下面的测试代码：

 

 

 

因为各个线程在执行的时候都是有cpu调度的，有可能会出现在thread1中删除n号元素后cpu直接将当代线程挂起，转而执行thread2的Sysout.out.println(vector.get(n))这不就报错了嘛！

 

1. 相对线程安全：相对安全就是我们同常意义上所讲的线程安全，它需要保证这个对象单独操作是线程安全的，我们在调用的时候不需要二外的保障措施，但是对于一些特定顺序的连续调用，就可能需要在调用端使用额外的同步手段来保证调用的正确性。上面的vector就是一个很好的例子。
2. 线程兼容：线程兼容是指对象本身并不是线程安全的，但是可以通过在调用端正确地使用同步手段来保证对象在并发环境中可以安全的使用，我们平常说一个类不是线程安全的，绝大多数是指“线程兼容这一种情况”。Java API中大部分类都属于线程兼容的，如和前面讲过的线程安全的Vector和HashTable相对应的集合类ArrayList和HashMap等。
3. 线程对立：线程对立是指无论调用端是否采取同步措施，都无法在多线程环境中并发使用的代码。由于Java语言天生就具备多线程的特性，线程对立这种排斥多线程的代码很少出现，而且通常都是有害的，应当避免。比如Thread类的suspend()和resume()就是线程对立的，很容易造成死锁，所以它两都被废弃了。

 

 

 

 

二.线程安全的实现方法

 

1. 互斥同步：

互斥同步是常见的一种并发正确性保证手段。同步是指在多线程并发访问共享数据时，保证共享数据在同一个时刻只被一个线程使用。互斥是实现同步的一种手段。因此，在这四个字里面，互斥是因，同步是果：互斥是方法，同步是目的。

 

 

在Java中，最基本的互斥同步手段就是synchronized关键字，synchronized关键字经过编译后，会在同步块的前后分别形成monitorenter和monitorexit这两个字节码指令，这两个字节码都需要一个reference类型的参数来指明要锁定和解锁的对象。

 

除了synchronized之外，我们还可以使用java.util.concurrent(下面简称J.U.C)包中的重入锁来实现同步，基本用法和synchronized很相似，synchronized表现为API层面的互斥锁，重入锁表现为原生语法层面的互斥锁。不过相比synchronized,ReentrantLock增加了一些高级宫娥能，主要有以下3项：等待可中断，可实现公平锁，以及锁可以绑定多个条件。

1. 等待可中断：指当持有锁的线程长期不释放锁，正在阻塞状态的线程可以选择放弃等待，转而处理其它事情。
2. 公平锁：是指多个线程在等待一个锁时，必须按照申请锁的时间顺序来一次获得锁。而非公平锁则不保证这一点。synchronized中的锁时非公平的，ReentrantLock默认也是非公平的，但可以通过带布尔值的构造函数要求使用公平锁。
3. 锁定多个条件：是指ReentrantLock对象可以同时绑定多个Condition对象。

 

我们应该有选择型：

虽然在JDK1.6发布之后，synchronized与ReentrantLock的性能基本上持平了，但是我们建议在两种锁都能使用的情况先优先使用synchronized因为虚拟机未来的新能优化中肯定会偏向于原生的synchronized。

 

 

还有，互斥同步最主要的问题就是进行线程阻塞和唤醒带来的性能问题，因此这种同步也称为阻塞同步。从问题处理的方式上来说，互斥同步属于悲观并发，总是认为只要不去做正确的访问同步措施(例如加锁)，那就肯定会出现问题，无论共享数据是否整的存在竞争，它都要加锁。

 

2.非阻塞同步

 

乐观并发与非阻塞同步：

与上面的互斥同步不同的，非阻塞同步是基于冲突检测的乐观并发策略，通俗的说，就是现进行操作，如果没有其他线程争抢共享数据，那操作就成功了；如果共享数据有争抢，产生了冲突，那就采取补偿措施(最常见的补偿措施就是不断的重试，直到成功为止)，这种乐观的并发策略的许多实现都不需要把线程挂起，一次这种同步操作称为非阻塞同步。

 

非阻塞同步需要依靠硬件实现：

为什么笔者说使用乐观并发策略需要“硬件指令集合的发展”才能进行呢？因为我们需要操作和冲突检查这两个步骤具有原子性，靠什么来保证呢？如果这里再使用互斥同步就失去意义了，所以我们只能依靠硬件来完成这件事请，硬件保证一个从语义上看起来需要多次操作的行为只通过一条处理器指令就能完成。

 

 

 

3.无同步方案

 

要保证线程安全，并不一定要进行同步，两者没有因果关系。同步只是保证共享数据争用时的正确性手段，如果一个方法本来就不涉及共享数据，那自然就无需任何同步措施去保证正确性，因此会有一些代码天生就是线程安全的，这里简单介绍两类：

 

1. 可重入代码（Reentrant Code）：这种代码也叫纯代码（Pure Code），可以在代码执行的任何时刻去中断它，转而执行另一段代码，而在控制权返回之后，原来的程序不会出现任何错误。可重入的代码都是线程安全的，但是线程安全的代码并不一定是可重入的。如果一个方法，它的返回值结果是可以预测的，只要输入了相同的数据，就能返回相同的结果，那它就满足可重入性的要求，当然也是线程安全的。
2. 线程本地存储(Thread Local Storage)：如果一段代码中所需要的数据必须与其他代码共享，那就可以把共享数据的可见范围限制在同一个线程之内，这样，无需同步也能保证线程安全。