Java并行程序基础 --- 多线程及容错性处理

最新推荐文章于 2022-08-24 21:49:28 发布

weixin_33955681

最新推荐文章于 2022-08-24 21:49:28 发布

阅读量280

点赞数

文章标签： java python

原文链接：https://my.oschina.net/u/2484728/blog/896943

版权

2019独角兽企业重金招聘Python工程师标准>>>

1. Java中提供的多线程编程手段

1.1 JDK5之前

只有synchronized一种

1.2 JDK5到现在：

Atomic
Lock
AtomicStampedReference
ReentrantLock

2 多线程编程容易产生的问题

2.1 共享状态

大家都知道，计算机在执行程序时，每条指令都是在CPU中执行的，而执行指令过程中，势必涉及到数据的读取和写入。由于程序运行过程中的临时数据是存放在主存（物理内存）当中的，这时就存在一个问题，由于CPU执行速度很快，而从内存读取数据和向内存写入数据的过程跟CPU比起来要慢的多，因此如果任何时间对数据的操作都要通过和内存的交互来进行，会大大降低指令执行的速度。因此在CPU里面就有了高速缓存。

也就是，当程序在运行过程中，会将运算需要的数据从主存复制一份到CPU的高速缓存当中，那么CPU进行计算时就可以直接从它的高速缓存读取数据和向其中写入数据，当运算结束后，再将高速缓存中的数据刷新到主存当中。举个简单的例子，比如下面的这段代码：

i=i+1

当线程执行这个语句时，会先从主存当中读取i的值，然后复制一份到高速缓存当中，然后CPU执行指令对i进行加1操作，然后将数据写入高速缓存，最后将高速缓存中i最新的值刷新到主存当中。

这个代码在单线程中运行是没有任何问题的，但是在多线程中运行就会有问题了。在多核CPU中，每条线程可以运行于不同的CPU中，因此每个线程运行时有自己的高速缓存（对单核CPU来说，其实也会出现这种问题。只不过是以线程调度的形式来分别执行的）。本文我们以多核CU为例。

下图中，线程1和线程2共享i,并同时对i进行i++操作，可能存在这种情况，最终结果i的值是1，而不是2。这就是著名的缓存一致性问题。

为了解决缓存不一致问题，通常来说有以下2种解决方法：

通过在总线加Lock#锁的方式
通过缓存一致性协议

这两种方式都是硬件层面上提供的方式。

在早期的CPU当中，是通过在总线加Lock#锁的形式来解决缓存不一致的问题。因为CPU和其他部件进行通信都是通过总线来进行的，如果对总线加Lock#锁的话，也就是说阻塞了其他CPU对其他部件访问（如内存），从而使得只有一个CPU能使用这个变量的内存。比如上面例子中，如果一个线程在执行i=i+1过程中，在总线上发出了LOCK#锁的信号，那么只有等待这段代码完全执行完毕之后，其他CPU才能从变量i所在的内存读取变量。这样就解决了缓存不一致的问题。

但是上面的方式会有一个问题，由于在锁定总线期间，其他CPU无法访问内存，容易导致以下的Starvation（饥饿）和DeadLock（死锁）问题。

所以就出现了缓存一致性协议。最出名的就是Intel的MESI协议，MESI协议保证了每个缓存中使用的共享变量的副本是一致的。它的核心思想是：当CPU写数据时，如果发现操作的变量是共享变量，即在其他CPU中也存在该变量的副本，会发出信号通知其他CPU将该变量的缓存行置为无效状态，因此当其他CPU需要读取这个变量时，发现自己缓存中缓存该变量的缓存行是无效的，那么它就会从内存中重新读取。

2.2 Starvation（饥饿）

高优先级的线程可能会占用所有CPU资源使得低优先级线程无法运行
线程可能因为其他线程的竞争而无法进入一个同步块
Notify方法唤醒的总是其他线程以至于等待线程总是在sleep状态

2.3 DeadLock（死锁）

线程1锁定A,尔后尝试锁定B,线程2锁定B,尔后尝试锁定A,造成两个线程同时等待对方释放锁，进入死锁状态。

总结：多线程编程容易产生问题的根本原因在于锁

3. 锁的不同类型（详情请看《锁优化的思路和方法》的第二部分）

3.1 偏向锁

3.2 轻量级锁

3.3 自旋锁（Spinlock）

不用切换至内核态，可能会更高效

3.4 互斥锁(Mutex)或信号量

不占用CPU资源
会切换至内核态

4. Volatile

一个线程写，另外一个线程读取，可以保证共享变量的可见性
当两个线程同时读写共享变量，Volatile无效
Volatile的读写会引起缓存内容失效，造成每一次读写均需要从主内存读取。因此性能会受到影响

4.1 正确使用volatile

你只能在有限的一些情形下使用volatile变量替代锁。要是volatile变量提供理想的线程安全，必须同时满足下面两个条件：

对变量的写操作不依赖于当前值。
对变量没有包含在具有其他变量的不变式中。

实际上，这些条件表明，volatile变量不能用作线程安全计数器。虽然增量操作(x++)看起来类似一个单独操作，实际上它是一个有读取-修改-写入操作序列组成的组合操作，必须以原子方式执行，而volatile不能提供必须的原子性操作。

简单局其中使用一例：状态标志

也许实现volatile变量的规范使用仅仅是使用一个boolean状态标志，用于指示发生了一个重要的一次性时间，例如完成初始化或请求停机。

很多应用程序包含了一种控制结构，形式为"在还没有准备好停止程序时再执行一些工作"。如以下代码所示，将volatile变量作为状态标志使用：

volatile boolean shutdownRequested;

...

public void shutdown() { shutdownRequested = true; }

public void doWork() {
while (!shutdownRequested) {
// do stuff
}
}

很可能会从循环外部调用shutdown()方法 -- 即在另一个线程中 -- 因此，需要执行某种同步来确保正确实现shutdownRequested变量的可见性。相对于synchronized，这里非常适合使用volatile。

5. 互斥锁和信号量

Java中的互斥锁是synchronized或者Lock,而信号量是Semaphore。
互斥锁可以看作是信号量的一个特例：可以把互斥锁比作家里的卫生间，每次只能一个人进入，信号量比作是公共卫生间，有几个隔间就可以进入。
Synchronized是reentrant(可重入)的，即两个对同一个变量synchronized的方法a、b,一个线程可以在a内进入b。
Lock不是reentrant的，如果需要reentrancy,使用ReentrantLock。
Semaphore没有reentrancy的概念，Semaphore只关心还有多少空间，不论当前线程是否已经占有了空间，只要当前线程进入Semaphore,就会造成Semaphore的计数-1。
Java除有锁编程之外，同时支持原子变量，即本人另一篇博客《Java并行程序基础 --- 无锁》的内容。
原子变量是无锁编程，可以看作是volatile的扩展
原子变量在volatile的基础上，保证了对CAS（compare and swap）操作的支持，允许多个线程对同一个原子变量读写操作。
原子变量不能保证ABA问题，即一个变量的原始值为A,被修改为B,后又被修改为A，这时其他线程无法得知当前的A其实是经过两次修改后的值
对于ABA问题，可以加入版本号，通过AtomicStampedReference支持。

总结：