Java并发基础（二）——并发级别

淡淡的烟草味﹌ 2022-03-26 02:56 232阅读 0赞

### 概述 ###

根据并发的控制策略，可将并发的级别分为阻塞、无饥饿、无障碍、无锁、无等待五种。

### 阻塞 ###

当前线程是阻塞的，那其它线程在释放资源之前，当前线程是无法继续执行的。当我们使用synchronized关键字或重入锁时，得到的线程就是阻塞的线程。

synchronized和重入锁都试图在执行后续代码前，得到临界区的锁，如果得不到，线程就会被挂起等待，直到占有了所需要的资源。

### 无饥饿（Starvation-Free） ###

若线程有优先级，那么线程在调度的时候总会是倾向于先满足优先级高的线程，这样对同一资源的分配自然就不是会的公平的了（好比春运排队去买火车票，会有人插队）。对于非公平锁来说，允许优先级高的线程插队。这样有可能导致低优先级的线程产生饥饿。但如果是公平锁，就是按照先来后到的正常顺序，饥饿就不会产生，不管新来的线程优先级有多高，要想获得资源，都是必须排除，这样一来所有的线程都有机会执行。

### 无障碍（Obstruction-Free） ###

无障碍是一种最弱的非阻塞调度。两个线程如果无障碍的执行，那不会因为临界区的问题导致一方被挂起。换句话说，两个线程都能进入临界区。但这样一样就可以都修改共享的数据了，这样就容易出问题了。对于无障碍线程来讲，一旦检测到这种情况，它就会立即对自己所做的修改进行回滚，确保数据安全。但如果没有数据竞争发生，那么线程就可以顺利完成自己的工作，走出临界区。

如果说阻塞的控制方式是悲观策略，即系统认为两个线程之间很可能发生不幸的冲突，因为以保护共享数据为第一优先级相对而言，非阻塞的调度就是一种乐观的策略。它认为多个线程之间很有可能不会发生冲突，或者说这种冲突的概率不大。因此大家都应该无障碍的执行，但是一旦检测到冲突，就应该进行回滚。

从这个策略中可以看到，无障碍的多线程程序并不一定能顺畅运行。因为当临界区中存在严重的冲突时，所有的线程可能都会不断的回滚自己的操作，而没有一个线程可以走出临界区。这种情况会影响系统的正常运行。所以可能会非常的希望在这一堆线程中，至少可以有一个线程能够在有限的时间内完成自己的操作，然后退出临界区。至少这样可以保证系统不会在临界区进行无限的等待。

一种可行的无障碍实现可以依赖一个“一致性标记”来实现。线程在操作之前，先读取并保存这个标记，在保存操作完成后再读取，检查这个标记是否被更改过，如果两个是一致的，则说明资源访问没有冲突。如果不一致，则说明资源可能在操作过程中与其它写线程有冲突，需要重试操作。而任何对资源有修改操作的线程，在修改数据前，都需要更新这个一致性标记，表示数据不再安全。

### 无锁（Lock-Free） ###

无锁的并行都是无障碍的。在无锁的情况下，所有的线程都能尝试对临界区进行访问，但不同的是，无锁的并发保证必然有一个线程能够在有限步内完成操作然后离开临界区。

在无锁的调用中，一个典型的特点是可能会包含一个无穷循环。在这个循环中，线程会不断尝试修改共享变量。如果没有冲突，修改成功后程序退出，否则继续尝试修改。但无论如何，无锁的并行总能保证有一个线程是可以胜出的，不至于全军覆没。至于临界区中竞争失败的线程，它们必须不断重试，直到自己获胜。如果运气很不好，总是尝试不成功，则会出现 类似饥饿的现象，线程会停止。

下面就是一段的示意代码，如果修改不成功，那么循环永远不会停止。

while(!atomicVar.compareAndSet(localVar, localVar+1)){
        localVar = atomicVar.get();
    }

### 无等待（Wait-Free） ###

无锁只要求有一个线程可以在有限步内完成操作，而无等待则在无锁的基础上更进一步。它要求所有的线程都必须在有限步内完成，这样就不会引起饥饿问题。如果限制这个步骤的上限，还可以进一步分解为有界无等待和线程数无关的无等待等几种，它们之间的区别只是对循环次数的限制不同。

一种典型的无等待结构就是RCU（Read Copy Update）。它的基本意思是，对数据的读可以不加控制。因此所有的读线程都是无等待的，它们既不会被锁定等待也不会引起任何冲突。但在写数据的时候，先取得原始数据的副本，接着只修改副本数据（这就是为什么读可以不加控制），修改完成后，在合适的时间回写数据。

注：以上内容参考《实战Java高并发程序设计（第2版）》。