Java线程----安全篇-CSDN博客

本文链接：https://blog.csdn.net/omyrobin/article/details/98724165

本篇是Java线程系列的第三篇，前两篇地址如下

线程安全

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

以上是引用自《Java Concurrency In Practice》的作者 Brian Goetz对“线程安全”有一个比较恰当的定义

我们姑且来分析下这句话的描述，首先多线程下方法一个对象。单线程是没有线程安全问题的，线程安全问题都是发生在并发也就是多线程编程上。因为单线程下代码都是顺序执行的，即使在指令重排序优化下，也不会影响结果的正确性。

既然多线程会引发线程安全问题，那么我们为什么要使用多线程呢？

多线程可以充分发挥现代计算机下多核CPU的性能
避免阻塞，单线程如果遇到阻塞只能等待，而多线程可以异步执行
在满足条件的情况下，多线程提高性能

这里只是简述了多线程的好处，详情可以去Google!

那么为什么使用多线程就会引发线程安全问题？

这就要去了解一下物理计算机了，现代的计算机绝大多数的运算任务都不可能只靠处理器“计算”就能完成，处理器至少要与内存交互。
由于计算机的存储设备与处理器的运算速度有几个数量级的差距（不得不佩服这些开发处理器的大佬），所以现代计算机系统都不得不加入一层读写速度尽可能接近处理器运算速度的高速缓存来做内存和处理器之间的缓冲，但是这样就引入了一个新的问题：缓存一致性。
而Java的内存模型和物理机上的结构有很高的相似性，JVM内存模型规定了所有的变量都存储在主内存中，每条线程还有自己的工作内存，线程的工作内存中保存了被该线程使用到的变量的主内存副本拷贝，线程对变量的所有操作都必须在工作内存中进行，而不能直接读写主内存的变量。不同线程之间也无法直接访问对方工作内存中的变量，线程间变量值的传递均需要通过主内存来完成，所以在并发情况下多线程操作共享变量后会产生线程安全问题。

除了高速缓存之外，处理器可能会对输入的代码进行乱序执行优化，处理器会在计算之后将乱序执行的结果重组，保证该结果与顺序执行的结果是一致的，但并不保证程序中各个语句计算的先后顺序与输入代码中的顺序一致，因此，如果存在一个计算任务依赖另一个计算任务的中间结果，那么其顺序行不能靠代码的先后顺序来保证，JVM也有类似的执行重排序优化
也就是说多线程下，指令重排序可能引发计算结果并不是预期结果的问题。

注：Java中有一个比较重要的概念就是happens-before “天然的”先行发生关系。

小结

也就是说造成多线程下线程安全问题的原因：

缓存一致性问题
指令重排序问题

以上这两个问题都跟JVM的有关，缓存一致性问题是JVM内存模型所决定的，指令重排序也是JVM在编译优化字节码指令时决定的。

Java语言中各种操作共享数据分为以下5类：不可变、绝对线程安全、相对线程安全、线程兼容和线程对立。

1.不可变
不可变得对象一定是线程安全的，无论是对象的方法实现还是方法的调用者，都不需要采用任何线程安全保障措施。

2.绝对线程安全
绝对线程安全就是满足上面Brian Goetz给出的线程安全的定义，但是这种“绝对”，其实要求非常严格，一般很难达到。即使Java API中标注自己是线程安全的类，大多数都不是绝对线程安全的，要在一定可控的使用范围下。

3.相对线程安全
相对线程安全就是我们通常意义上所讲的线程安全，它需要保证对这个对象单独的操作是线程安全的，我们在调用的时候不需要做额外的保障措施，但是对于一些特定顺序的连续调用，就可能需要在调用端使用额外额同步手段来保证调用的正确性。
在Java语言中，大部分的线程安全类都属于这种类型。

4.线程兼容
线程兼容是指对象本事并不是线程安全的，但是可以通过在调用端正确地使用同步手段来保证对象在并发环境中可以安全地使用，我们平常说一个类不是线程安全的，绝大多数时候指的是这一种情况。

5.线程对立
线程对立是指无论调用端是否采取了同步措施，都无法在多线程环境中并发使用的代码。

线程安全的实现方法

了解了什么是线程安全之后，那我们如何实现线程安全呢？

线程安全与代码编写有很大的关系，但虚拟机提供的同步和锁机制也起到了非常重要的作用。

1.互斥同步
互斥同步（Mutual Exclusion & Synchronization）是常见的一种并发正确性保障手段。
同步是指在多线程并发访问共享数据时，保证共享数据在同一时刻只被一个（或者是一些，使用信号量的时候）线程使用。而互斥是实现同步的一种手段，临界区、互斥量和信号量都是主要的互斥实现手段。

在Java中，最基本的互斥同步手段就是synchronized关键字，synchronized关键字经过编译之后，会在同步块的前后分别形成monitorenter和monitorexit这两个字节码指令。
在虚拟机规范中对monitorenter和monitorexit的行为描述中，有两点需要特别注意：

synchronized同步块对于同一条线程来说是可重入的，不会出现自己把自己锁死的问题。
同步块在已进入的线程执行完之前，会阻塞后面其他线程的进入。

对于Java的线程实现方式来说，这种阻塞操作，都需要操作系统来帮忙完成，需要从用户态和内核态中进行状态转换，因此状态转换需要耗费很多的处理器时间。

除了synchronized之外，我们还可以使用java.util.concurrent包中的重入锁（ReentrantLock）来实现同步。
关于synchronized和ReentrantLock区别我找时间再开一篇来详细介绍，这也是面试常考的问题之一。

2.非阻塞同步
互斥同步最主要的问题就是进行线程阻塞和唤醒所带来的性能问题，因此这种同步也称为阻塞同（BlockingSynchronization）。从处理问题的方式上说，互斥同步属于一种悲观的并发策略，总是认为只要不去做正确的同步措施（例如加锁），那就肯定会出现问题，无论共享数据是否真的会出现竞争，它都要进行加锁（这里讨论的是概念模型，实际上虚拟机会优化掉很大一部分不必要的加锁）、用户态核心态转换、维护锁计数器和检查是否有被阻塞的线程需要唤醒等操作。随着硬件指令集的发展，我们有了另外一个选择：基于冲突检测的乐观并发策略，通俗地说，就是先进行操作，如果没有其他线程争用共享数据，那操作就成功了；如果共享数据有争用，产生了冲突，那就再采取其他的补偿措施（最常见的补偿措施就是不断地重试，直到成功为止），这种乐观的并发策略的许多实现都不需要把线程挂起，因此这种同步操作称为非阻塞同步（Non-Blocking Synchronization）。

这里就是面试中常问到的悲观锁和乐观锁。

悲观锁：假定会发生并发冲突，屏蔽一切可能违反数据完整性的操作。
乐观锁：假设不会发生并发冲突，只在提交操作时检查是否违反数据完整性。乐观锁不能解决脏读的问题。
Java中的乐观锁和悲观锁：我们都知道，cpu是时分复用的，也就是把cpu的时间片，分配给不同的thread/process轮流执行，时间片与时间片之间，需要进行cpu切换，也就是会发生进程的切换。切换涉及到清空寄存器，缓存数据。然后重新加载新的thread所需数据。当一个线程被挂起时，加入到阻塞队列，在一定的时间或条件下，在通过notify()，notifyAll()唤醒回来。在某个资源不可用的时候，就将cpu让出，把当前等待线程切换为阻塞状态。等到资源(比如一个共享数据）可用了，那么就将线程唤醒，让他进入runnable状态等待cpu调度。这就是典型的悲观锁的实现。独占锁是一种悲观锁，synchronized就是一种独占锁，它假设最坏的情况，并且只有在确保其它线程不会造成干扰的情况下执行，会导致其它所有需要锁的线程挂起，等待持有锁的线程释放锁。
但是，由于在进程挂起和恢复执行过程中存在着很大的开销。当一个线程正在等待锁时，它不能做任何事，所以悲观锁有很大的缺点。举个例子，如果一个线程需要某个资源，但是这个资源的占用时间很短，当线程第一次抢占这个资源时，可能这个资源被占用，如果此时挂起这个线程，可能立刻就发现资源可用，然后又需要花费很长的时间重新抢占锁，时间代价就会非常的高。
所以就有了乐观锁的概念，他的核心思路就是，每次不加锁而是假设没有冲突而去完成某项操作，如果因为冲突失败就重试，直到成功为止。在上面的例子中，某个线程可以不让出cpu,而是一直while循环，如果失败就重试，直到成功为止。所以，当数据争用不严重时，乐观锁效果更好。比如CAS就是一种乐观锁思想的应用。

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

这类指令常用的有：

测试并设置（Test-and-Set）。
获取并增加（Fetch-and-Increment）。
交换（Swap）。
比较并交换（Compare-and-Swap，下文称CAS）。
加载链接/条件存储（Load-Linked/Store-Conditional，下文称LL/SC）。

其中，前面的3条是20世纪就已经存在于大多数指令集之中的处理器指令，后面的两条是现代处理器新增的，而且这两条指令的目的和功能是类似的。在IA64、x86指令集中有cmpxchg指令完成CAS功能，在sparc-TSO也有casa指令实现，而在ARM和PowerPC架构下，则需要使用一对ldrex/strex指令来完成LL/SC的功能。

CAS指令需要有3个操作数，分别是内存位置（在Java中可以简单理解为变量的内存地址，用V表示）、旧的预期值（用A表示）和新值（用B表示）。CAS指令执行时，当且仅当V符合旧预期值A时，处理器用新值B更新V的值，否则它就不执行更新，但是无论是否更新了V的值，都会返回V的旧值，上述的处理过程是一个原子操作。

3.无同步方案
要保证线程安全，并不是一定就要进行同步，两者没有因果关系。同步只是保证共享数据争用时的正确性手段，如果一个方法本来就不涉及共享数据，那么它自然就无须任何同步措施去保证正确性，因此会有一些代码天生就是线程安全的。
可重入代码： 这种代码也叫做纯代码，可以在代码执行的任何时刻中断它，转而去执行另一段代码，而在控制权返回后，原来程序不会出现错误。简而言之就是线程的上下文切换不会影响线程最终的执行结果。对于相对线程安全来说，可重入性是更基本的特征。

可重入代码有一些共同的特征，例如不依赖存在堆上的数据和公有的系统资源、用到的状态量都由参数中传入、不调用非可重入方法等。还记得我们的缓存一致性问题吗，依赖于JVM的内存模型，在JVM运行时数据区中，虚拟机栈和本地方法栈以及程序计数器都是线程私有的，而Java方法中基本数据类型这类局部变量都是存储在虚拟机栈中的，也就是天然的线程安全。这种线程私有内存存储位置就是这种“天然”的原因。

线程本地存储： 如果一段代码中所需要的数据必须与其他的代码共享，那就看看这些共享数据的代码能否保证在同一个线程中执行，如果能保证就可以把共享数据的可见范围限制在同一个线程之内，这样无需同步也能保证线程之间不出现数据争用的问题。
这句话对于我理解起来我觉得有些费解，因为线程本地存储我能想到的Java实现方案就是ThreadLocal类，这也是Android面试中关于消息机制Handler中会引出的经典面试问题。其实我从通俗上讲，如果变量不在虚拟机栈这种线程私有的内存存储位置上，而是出现在堆中，这种线程共享的内存存储位置上，我们如何保证安全性，就好比一个苹果，大家都想吃，谁都来抢，那么这个苹果肯定不安全,那么我们如果能缺点这个苹果能保证在一个线程作用域范围安全使用，那么我们可以每人发一个苹果，大家就不用抢了，这就是我认为的ThreadLocal解决方案。