谈一谈Java编程开发中的并发控制

并发指在宏观上的同一时间内同时执行多个任务。为了满足这一需求，现代的操作系统都抽象出线程的概念，供上层应用使用。

这篇博文不打算详细展开分析，而是对java并发中的概念和工具做一个梳理。
沿着并发模型、并发要解决的问题、基本工具、衍生工具这一思路展开。

线程

首先线程是什么？线程是由OS抽象并实现的，我们知道OS的职责是管理并合理分配硬件资源，那么OS为了更好的管理、分配CPU资源，同时也为了满足同时执行任务这一需求，设计了线程这一概念。

虽然java程序运行在JVM虚拟机上，但是java的线程仍然是对操作系统原生线程的封装，同时，jvm对线程实现时也将jvm的运行栈设计成线程私有内存，因此，java线程和原生线程在理解上实际上没太大区别。

线程的五种状态：

graph LR
新建 --> 就绪;
就绪 --> 运行;
运行 --> 就绪;
运行 --> 阻塞;
阻塞 --> 就绪;
运行 --> 死亡;

先来看上面的就绪状态和运行状态。我们知道线程虽然宏观上是同时执行的，但是微观上使用如时间片轮转算法使得线程依次执行。那么，同一时间只有一个线程执行，其它需要执行的线程处于 就绪队列 中，等待自己被调度到。

而如果线程想要暂时放弃在CPU上运行的权利，就会阻塞自己。这时对应着阻塞状态，同时线程会从就绪队列中移除，进入等待队列。
很显然，阻塞线程被唤醒肯定是进入就绪队列等待调度，而不可能是直接分配到CPU上运行。

在线程同步时，线程可能由于以下情况被阻塞：

同步阻塞。就是被锁阻塞。
等待阻塞。被条件变量阻塞。
其它。调用sleep(), join()或等待IO操作时的阻塞。

并发需要解决的问题

功能性问题

线程同步面临两个问题，想象下有两个线程在协作工作完成某项任务。那么需要解决以下问题：

线程两个线程之间交互数据，必然涉及到数据共享。而某些数据资源无法被多个线程同时使用（临界区），这时需要，即线程互斥问题。
假如一个线程进行的太快，另外一个线程就需要等等它，即线程同步问题。

性能和可用性问题

在多线程程序的性能问题上，如果是对于同样一段临界区的多线程访问，那么则有以下几个思路：

互斥锁。互斥锁即保证同一时间只有一个线程访问临界区并完整执行完，其它线程在临界区外面等待。
无障碍或无锁。线程们一开始直接进入临界区执行，注意其中不能修改共享数据。执行完后再判断刚才这段时间是否有其它线程执行，没有的话才修改共享数据，如果有的话就回滚重来。
降低锁粒度。也即将这个大的临界区拆分成几个小的临界区，分别加互斥锁控制，这样提高了线程同时访问的临界区的机会变多，性能提高。显然这要对代码仔细推敲，考虑如何拆分锁粒度而不影响整体的语义。

以上三种思路的性能优劣没有一个普适的结果，和具体的场景相关。

并发中还会出现以下几种情况导致系统不可用：

死锁。不解释。
饥饿。线程调度算法如果不是平等分配的，那么就可能出现优先级高的线程长时间占用CPU，导致优先级低的线程无法得到执行机会。
活锁。这个我解释不来。。。

并发代码的几个性质

并发编程中需要考虑的几个概念：

原子性：指某个操作一旦被某个线程执行，直到该操作执行完毕都不会有其它线程来干扰。
可见性：指某个变量或某块内存如果被A线程修改，B线程能否马上读取到修改后的值。
有序性：A线程执行的代码序列，在B线程看来是否是有序的。

从我个人的理解来看，原子性属于由并发和线程这一理论概念自然而然推导衍生而来的概念，而可见性和有序性是具体的工程实践中产生的。
实际中，jvm并不能实现的特别完美，总会有工程上的妥协。理论模型与实际模型无法完美契合，总存在一定的偏差。
比如说，jvm为了向性能妥协使用了缓存机制，牺牲了数据一致性，这就产生了可见性的概念，需要程序员编程时自己控制。
jvm为了指令更高效率的执行进行了指令重排优化，则产生了有序性的问题。印象里以前大学里学过的CPU的流水线技术，为了指令能够更好的被CPU流水线利用，减少流水线的空闲时间，编译器编译时也会在不影响 串行语义 的前提下，进行指令重排。
总而言之，这是在性能和理论模型完整性之间的一种妥协。