一篇文章看懂Java并发和线程安全（一）

1、前言

    长久以来，一直想剖析一下Java线程安全的本质，可是苦于有些微观的点想不明白，便搁置了下来，前段时间慢慢想明白了，便把全部的点串联起来，趁着思路清晰，整理成这样一篇文章。

2、导读

    一、为何有多线程？

    二、线程安全描述的本质问题是什么？

    三、Java内存模型(JMM)数据可见性问题、指令重排序、内存屏障

3、揭晓答案

一、为何有多线程

    谈到多线程，咱们很容易与高性能画上等号，可是并不是如此，举个简单的例子，从1加到100，用四个线程计算不必定比一个线程来得快。由于线程的建立和上下文切换，是一笔巨大的开销。

    那么设计多线程的初衷是什么呢？来看一个这样的实际例子，计算机一般须要与人来交互，假设计算机只有一个线程，而且这个线程在等待用户的输入，那么在等待的过程当中，CPU什么事情也作不了，只能等待，形成CPU的利用率很低。若是设计成多线程，在CPU在等待资源的过程当中，能够切到其余的线程上去，提升CPU利用率。

    现代处理器大多含有多个CPU核心，那么对于运算量大任务，能够用多线程的方式拆解成多个小任务并发的执行，提升计算的效率。

    总结起来无非两点，提升CPU的利用率、提升计算效率。

二、线程安全的本质

    咱们先来看一个例子：

public class Add {
	private int count = 0;

	public static void main(String[] args) {
		CountDownLatch countDownLatch = new CountDownLatch(4);
		Add add = new Add();
		add.doAdd(countDownLatch);
		try {
			countDownLatch.await();
		} catch (InterruptedException e) {
			e.printStackTrace();
		}
		System.out.println(add.getCount());

	}
	public void doAdd(CountDownLatch countDownLatch) {
		for (int i = 0; i < 4; i++) {
			new Thread(new Runnable() {
				public void run() {
					for (int j = 0; j < 25; j++) {
						count++;
					}
					countDownLatch.countDown();
				}
			}).start();
		}
	}

	public int getCount() {
		return count;
	}

}

    上面是一个把变量自增100次的例子，只不过用了4个线程，每一个线程自增25次，用CountDownLatch等4个线程执行完，打印出最终结果。实际上，咱们但愿程序的结果是100，可是打印出来的结果并不是老是100。

    这就引出了线程安全所描述的问题，咱们先用通俗的话来描述一下线程安全：

    线程安全就是要让程序运行出咱们想要的结果，或者话句话说，让程序像咱们看到的那样执行。

    解释一下我总结的这句话，咱们先new出了一个add对象，调用了对象的doAdd方法，原本咱们但愿每一个线程有序的自增25次，最终获得正确的结果。若是程序增的像咱们预先设定的那样运行，那么这个对象就是线程安全的。

    下面咱们来看看Brian Goetz对线程安全的描述：当多线程访问一个对象时，若是不用考虑这些线程在运行时环境下的调度和交替，也不须要进行额外的同步，或者在调用方进行任何其余的协调操做，调用这个对象的行为均可以得到正确的结果，那么这个对象就是线程安全的。

    下面咱们就来分析这段代码为何不能确保老是获得正确的结果。

    三、Java内存模型(JMM)数据可见性问题、指令重排序、内存屏障

    先从计算机的硬件效率提及，CPU的计算速度比内存快几个数量级，为了平衡CPU和内存之间的矛盾，引入的高速缓存，每一个CPU都有高速缓存，甚至是多级缓存L一、L2和L3，那么缓存与内存的交互须要缓存一致性协议，这里就不深刻讲解。那么最终处理器、高速缓存、主内存的交互关系以下：

    那么Java的内存模型（Java Memory Model，简称JMM）也定义了线程、工做内存、主内存之间的关系，很是相似于硬件方面的定义。

    这里顺带提一下，Java虚拟机运行时内存的区域划分

    方法区：存储类信息、常量、静态变量等，各线程共享

    虚拟机栈：每一个方法的执行都会建立栈帧，用于存储局部变量、操做数栈、动态连接等，虚拟机栈主要存储这些信息，线程私有

    本地方法栈：虚拟机使用到的Native方法服务，例如c程序等，线程私有

    程序计数器：记录程序运行到哪一行了，至关于当前线程字节码的行号计数器，线程私有

    堆：new出的实例对象都存储在这个区域，是GC的主战场，线程共享。

    因此对于JMM定义的主内存，大部分时候能够对应堆内存、方法区等线程共享的区域，这里只是概念上对应，其实程序计数器、虚拟机栈等也有部分是放在主内存的，具体看虚拟机的设计。

    好了，了解了JMM内存模型，咱们来分析一下，上面的程序为何没获得正确的结果。请看下图，线程A、B同时去读取主内存的count初始值存放在各自的工做内存里，同时执行了自增操做，写回主内存，最终获得了错误的结果。

    咱们再来深刻分析一下，形成这个错误的本质缘由：

    （1）、可见性，工做内存的最新值不知道何时会写回主内存

    （2）、有序性，线程之间必须是有序的访问共享变量，咱们用“视界”这个概念来描述一下这个过程，以B线程的视角看，当他看到A线程运算好以后，把值写回以内存以后，立刻去读取最新的值来作运算。A线程也应该是看到B运算完以后，立刻去读取，在作运算，这样就获得了正确的结果。

    接下来，咱们来具体分析一下，为何要从可见性和有序性两个方面来限定。

    给count加上volatile关键字，就保证了可见性。

private volatile int count = 0;

    volatile关键字，会在最终编译出来的指令上加上lock前缀，lock前缀的指令作三件事情

    （1）、防止指令重排序（这里对本问题的分析不重要，后面会详细来说）

    （2）、锁住总线或者使用锁定缓存来保证执行的原子性，早期的处理可能用锁定总线的方式，这样其余处理器没办法经过总线访问内存，开销比较大，如今的处理器都是用锁定缓存的方式，在配合缓存一致性来解决。

    （3）、把缓冲区的全部数据都写回主内存，并保证其余处理器缓存的该变量失效

    既然保证了可见性，加上了volatile关键词，为何仍是没法获得正确的结果，缘由是count++，并不是原子操做，count++等效于以下步骤：

   （1）、 从主内存中读取count赋值给线程副本变量：

            temp=count

    （2）、线程副本变量加1

            temp=temp+1

    （3）、线程副本变量写回主内存

            count=temp

    就算是真的严苛的给总线加锁，致使同一时刻，只能有一个处理器访问到count变量，可是在执行第（2）步操做时，其余cpu已经能够访问count变量，此时最新运算结果还没刷回主内存，形成了错误的结果，因此必须保证顺序性。

    那么保证顺序性的本质，就是保证同一时刻只有一个CPU能够执行临界区代码。这时候作法一般是加锁，锁本质是分两种：悲观锁和乐观锁。如典型的悲观锁synchronized、JUC包下面典型的乐观锁ReentrantLock。

    总结一下：要保证线程安全，必须保证两点：共享变量的可见性、临界区代码访问的顺序性。

    下一篇博客将从指令重排序、内存屏障等微观的角度，站在线程的视角来看一个乱序的Java世界，请关注下一篇博客《一篇文章看懂Java并发和线程安全（二）》

   

快乐源于分享。

此博客乃做者原创， 转载请注明出处