并发编程系列之线程并行学习笔记

文章目录

一、线程并行相关概念

同步(Synchronous)和异步(Asynchronous)

并发(Concurrency)和并行(Parallelism)

临界区

阻塞(Blocking)和非阻塞(Non-Blocking)

饥饿(Starvation)、死锁(Deadlock)和活锁(Livelock)

二、并行的两个重要定律

Amdahi定律

Gustafson定律

三、多线程的特性

原子性

可见性

有序性

一、线程并行相关概念

同步和异步的本质区别是是否需要等待，比如一个方法在执行，必须等前面一个方法程执行完成，才可以执行，这就是同步。如果不需要等上一个方法执行完成，并行或者并发执行，这就是异步调用。

并发和并行两个概念很容易混淆。解释起来意思也差不多，不过说起来，并行才是真正意义上的并行执行，并发只是线程的交替执行，有可能存在串行的情况。

在单核CPU的系统，线程只能是并发的，而不能支持并行，并行执行只能存在与多核CPU的系统。

临界区，可以理解为公共的资源或者说共享数据。临界区具有保护性，也就是说，只能一个线程占用临界区，一旦一个线程占了临界区，另外一个线程是不予许再占用的，必须等线程释放了才行。

阻塞是线程的一种比较严重的情况，从前面我们知道了临界区只能允许一个线程占用，假如一个线程因为执行时间过长，占用了临界区，不挂起，其它想要占用临界区的线程只能等待，这种情况就容易造成线程阻塞。非阻塞的话就相反了，指所有线程都正常执行，不会出现线程占临界区不挂起的情况。

饥饿，有些情况可能是一个线程优先级太低了，每次都被其它线程占用了，导致改线程一种不能占用临界区。也有一些情况是上一个线程执行时间太长了，一直没释放，导致其它线程都不能占用临界区，这也是造成线程饥饿。

死锁有可能是因为线程死循环调用等等情况造成的，一旦出现这种情况估计就得人工排查了。

活锁，解释一下，一般就是这样的情况，因为线程互相挂起临界区，给其它线程用，互相“谦让”，导致资源在两个或者几个线程之间跳到，这种情况就是活锁。

二、并行的两个重要定律

Amdahi定律定义了串行系统并行化后的加速比公式。

加速比定义：加速比 = 优化前系统耗时 / 优化后系统耗时

加速比越高，说明优化越明显。简单介绍一下Amdahi定律公式的推导。

优化后耗时T_n＝T1(F+1/n(1-F))，其中T1表示优化前耗时，F表示串行比例，(1-F)表示并行比例，下标n就是处理器的个数。

导入加速比公式，也就是T1/T_n，也就是1/(F + 1/n(1-F))，公式只是进行简单介绍。

从公式可以看出，加速比是和串行比例F成反比的，从公式可以看出增加cpu的个数仅仅是一种提供加速比的方法，增加cpu个数的同时，还可以提供降低串行比例来做，也就是串行比例F越低，加速比也就越高

Custafson公式也是并行的一个比较重要的公式，现在介绍一下Custafson公式的推导。

定义一下串行执行时间为a，并行执行时间为b。即单核CPU情况，执行时间为a+b总执行时间为a+nb，n表示CPU个数。

//定义串行比例

F=a/(a+b)

//得到加速比

s(n)=a+nb/a+b=a/a+b + nb/a+b = F + n*(b-a+a)/a+b = F + n(1-F)

从公式可以看出，如果串行比例足够小的情况，加速比其实就是约等于处理器个数，也就是说通过加多CPU的个数就能提高加速比。

两个公式看起来似乎有点矛盾，其实不然，两个公式只是从不同角度分析问题。Amdahi是说在串行比例一定时，通过加CPU的方法是有上限的，通过降低串行比例同时增加cpu个数可以提高加速比。Custafson是说在串行比较趋于很小的情况，从公式可以看出，加cpu就可以提高加速比

三、多线程的特性

因为多线程环境的数据不一致性和安全性，所以就需要一些规则类控制，Java的内存模型JMM就规范了多线程有效正确的执行，而JMM也正是围绕多线程的原子性、可见性、有序性进行的，所以本博客介绍一些多线程的原子性、可见性和有序性

对于单线程来说，确实是具有原子性的，比如一个int变量，改变一下值，去读取的时候是那个值，这是很正常的，我们去系统运行，也是这样的，因为我们的操作系统大部分是32位和64位的，int类型4个字节，也就是32位，不过可以试试long类型的数值，long类型是8个字节，也就是64位，如果两个线程都对其进行读写呢？在多线程环境，一个线程改变了long类型的值，然后再去读取，获取到的值就不一定是刚才改变的值了，因为你的系统可能是32位的，而long类型是64位的，如果两个线程都对long类型进行读写，就会出现这种情况。

对于可见性又应该怎么理解？首先说一下对于单线程来说，是并不存在可见性的，可见性是针对多线程来说的，比如，一个线程进行了改变，另外一个线程是否知道这个线程做了改变，这个就是可见性。举个例子，变量a是共享变量，一个cpu1上的变量a做了缓存优化，将变量a放在了缓存里，这时，另外一个cpu2上线程对变量a做了改变，这个操作对于cpu1上的线程是不可见的，因为cpu1已经做了缓存，所以cpu1上的线程就从缓存读取变量a了，发现和cpu2上读取的值并不一致。

对于单线程来说，一个线程的代码执行是按照先后顺序的，这样说是没错的，但是在多线程环境可不一定了。因为在多线程环境可能发生指令的重排。也就是说多线程环境，代码执行是不一定具有有序性的。

既然无序性是重排导致的，那么是所有的指令都会重排的？当然不是。重排按照：Happen-Before规则。

列举一下：

引用葛一鸣/郭超/. 实战Java高并发程序设计 (597-601).

程 序 顺 序 原 则： 一 个 线 程 内 保 证 语 义 的 串 行

性 volatile 规 则： volatile 变 量 的 写， 先 发 生 于 读， 这 保 证 了 volatile 变 量 的 可 见 性

锁 规 则： 解 锁（ unlock） 必 然 发 生 在 随 后 的 加 锁（ lock） 前

传 递 性： A 先 于 B， B 先 于 C， 那 么 A 必 然 先 于 C

线 程 的 start() 方 法 先 于 它 的 每 一 个 动 作

线 程 的 所 有 操 作 先 于 线 程 的 终 结（ Thread.join()）

线 程 的 中 断（ interrupt()） 先 于 被 中 断 线 程 的 代 码

对 象 的 构 造 函 数 执 行、 结 束 先 于 finalize() 方 法

任务调度 多线程

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。