一、线程安全问题的产生

线程安全问题：指的是在多线程编程中，同时操作同一个可变的资源之后，造成的实际结果与预期结果不一致的问题。

比如：A和B同时向C转账10万元。如果转账操作不具有原子性，A在向C转账时，读取了C的余额为20万，然后加上转账的10万，计算出此时应该有30万，但还未来及将30万写回C的账户，此时B的转账请求过来了，B发现C的余额为20万，然后将其加10万并写回。然后A的转账操作继续——将30万写回C的余额。这种情况下C的最终余额为30万，而非预期的40万。

如果上面的内容您还没有理解，没关系，我们来看下面非安全线程的模拟代码：

public class ThreadSafeSample {public int number;public void add() {for (int i = 0; i < 100000; i++) {int former = number++;int latter = number;if (former != latter-1){System.out.printf("非相等 former=" +  former + " latter=" + latter);}}}public static void main(String[] args) throws InterruptedException {ThreadSafeSample threadSafeSample = new ThreadSafeSample();Thread threadA = new Thread(new Runnable() {@Overridepublic void run() {threadSafeSample.add();}});Thread threadB = new Thread(new Runnable() {@Overridepublic void run() {threadSafeSample.add();}});threadA.start();threadB.start();threadA.join();threadB.join();}
}

我电脑运行的结果： 非相等 => former=5555 latter=6061

可以看到，仅仅是两个线程的低度并发，就非常容易碰到 former 和 latter 不相等的情况。这是因为，在两次取值的过程中，其他线程可能已经修改了number.

二、线程安全的解决方案

线程安全的解决方案分为以下几个维度（参考《码出高效：Java开发手册》）：

数据单线程可见（单线程操作自己的数据是不存在线程安全问题的，ThreadLocal就是采用这种解决方案）；
数据只读；
使用线程安全类（比如StringBuffer就是一个线程安全类，内部是使用synchronized实现的）；
同步与锁机制；

解决线程安全核心思想是：“要么只读，要么加锁”，解决线程安全的关键在于合理的使用Java提供的线程安全包java.util.concurrent简称JUC。

三、线程同步与锁

Java 5 以前，synchronized是仅有的同步手段，Java 5的时候增加了ReentrantLock（再入锁）它的语义和synchronized基本相同，比synchronized更加灵活，可以做到更多的细节控制，比如锁的公平性/非公平性指定。

3.1 synchronized

synchronized 是 Java 内置的同步机制，它提供了互斥的语义和可见性，当一个线程已经获取当前锁时，其他试图获取的线程只能等待或者阻塞在那里。

3.1.1 synchronized 使用

synchronized 可以用来修饰方法和代码块。

3.1.1.1 修饰代码块

synchronized (this) {int former = number++;int latter = number;//...
}

3.1.1.2 修饰方法

public synchronized void add() {//...
}

3.1.2 synchronized 底层实现原理

synchronized 是由一对 monitorenter/monitorexit 指令实现的，Monitor 对象是同步的基本实现单元。在 Java 6 之前，Monitor的实现完全是依靠操作系统内部的互斥锁，因为需要进行用户态到内核态的切换，所以同步操作是一个无差别的重量级操作，性能也很低。但在Java 6的时候，JVM 对此进行了大刀阔斧地改进，提供了三种不同的 Monitor 实现，也就是常说的三种不同的锁：偏向锁（Biased Locking）、轻量级锁和重量级锁，大大改进了其性能。

3.1.2.1 偏向锁/轻量级锁/重量级锁

偏向锁是为了解决在没有多线程的访问下，尽量减少锁带来的性能开销。

轻量级锁是指当锁是偏向锁的时候，被另一个线程所访问，偏向锁就会升级为轻量级锁，其他线程会通过自旋的形式尝试获取锁，不会阻塞，提高性能。

重量级锁是指当锁为轻量级锁的时候，另一个线程虽然是自旋，但自旋不会一直持续下去，当自旋一定次数的时候，还没有获取到锁，就会进入阻塞，该锁膨胀为重量级锁。重量级锁会让其他申请的线程进入阻塞，性能降低。

3.1.2.2 锁膨胀（升级）原理

Java 6 之后优化了 synchronized 实现方式，使用了偏向锁升级为轻量级锁再升级到重量级锁的方式，减低了锁带来的性能消耗，也就是我们常说的锁膨胀或者叫锁升级，那么它是怎么实现锁升级的呢？

锁膨胀（升级）原理： 在锁对象的对象头里面有一个ThreadId字段，在第一次访问的时候ThreadId为空，JVM让其持有偏向锁，并将ThreadId设置为其线程id，再次进入的时候会先判断ThreadId是否尤其线程id一致，如果一致则可以直接使用，如果不一致，则升级偏向锁为轻量级锁，通过自旋循环一定次数来获取锁，不会堵塞，执行一定次数之后就会升级为重量级锁，进入堵塞，整个过程就是锁膨胀（升级）的过程。

3.1.2.3 自旋锁

自旋锁是指尝试获取锁的线程不会立即阻塞，而是采用循环的方式去尝试获取锁，这样的好处是减少线程上下文切换的消耗，缺点是循环会消耗CPU。

3.1.2.4 乐观锁/悲观锁

悲观锁和乐观锁并不是某个具体的“锁”而是一种是并发编程的基本概念。

悲观锁认为对于同一个数据的并发操作，一定是会发生修改的，哪怕没有修改，也会认为修改。因此对于同一个数据的并发操作，悲观锁采取加锁的形式。悲观的认为，不加锁的并发操作一定会出问题。

乐观锁则与 Java 并发包中的 AtomicFieldUpdater 类似，也是利用 CAS 机制，并不会对数据加锁，而是通过对比数据的时间戳或者版本号，来实现乐观锁需要的版本判断。

3.1.2.5 公平锁/非公平锁

公平锁是指多个线程按照申请锁的顺序来获取锁。

非公平锁是指多个线程获取锁的顺序并不是按照申请锁的顺序，有可能后申请的线程比先申请的线程优先获取锁。

如果使用 synchronized 使用的是非公平锁，是不可设置的，这也是主流操作系统线程调度的选择。通用场景中，公平性未必有想象中的那么重要，Java 默认的调度策略很少会导致 “饥饿”发生。非公平锁的吞吐量大于公平锁。

非公平锁吞吐量大于公平锁的原因：

比如A占用锁的时候，B请求获取锁，发现被A占用之后，堵塞等待被唤醒，这个时候C同时来获取A占用的锁，如果是公平锁C后来者发现不可用之后一定排在B之后等待被唤醒，而非公平锁则可以让C先用，在B被唤醒之前C已经使用完成，从而节省了C等待和唤醒之间的性能消耗，这就是非公平锁比公平锁吞吐量大的原因。

3.2 ReentrantLock

ReentrantLock只能修饰代码块，使用ReentrantLock必须手动unlock释放锁，不然锁永远会被占用。

3.2.1 ReentrantLock 使用

ReentrantLock reentrantLock = new ReentrantLock(true); // 设置为true为公平锁，默认是非公平锁
reentrantLock.lock();
try {}finally {reentrantLock.unlock();
}

3.2.2 ReentrantLock 优势

具备尝试非阻塞地获取锁的特性：当前线程尝试获取锁，如果这一时刻锁没有被其他线程获取到，则成功获取并持有锁；
能被中断地获取锁的特性：与synchronized不同，获取到锁的线程能够响应中断，当获取到锁的线程被中断时，中断异常将会被抛出，同时锁会被释放；
超时获取锁的特性：在指定的时间范围内获取锁；如果截止时间到了仍然无法获取锁则返回。

3.2.3 ReentrantLock 注意事项

在finally中释放锁，目的是保证在获取锁之后，最终能够被释放；
不要将获取锁的过程写在try块内，因为如果在获取锁时发生了异常，异常抛出的同时，也会导致锁无故被释放；
ReentrantLock提供了一个newCondition的方法，以便用户在同一锁的情况下可以根据不同的情况执行等待或唤醒的动作；

3.3 synchronized和ReentrantLock区别

从性能角度，synchronized 早期的实现比较低效，对比 ReentrantLock，大多数场景性能都相差较大。但是在 Java 6 中对其进行了非常多的改进，在高竞争情况下，ReentrantLock 仍然有一定优势。在大多数情况下，无需太纠结于性能，还是考虑代码书写结构的便利性、可维护性等。

主要区别如下：