前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >线程并行学习笔记

线程并行学习笔记

作者头像
SmileNicky
发布2019-01-17 16:22:40
3860
发布2019-01-17 16:22:40
举报
文章被收录于专栏:Nicky's blogNicky's blog

一、线程并行相关概念

同步(Synchronous)和异步(Asynchronous)

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

并发(Concurrency)和并行(Parallelism)

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

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

临界区

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

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

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

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

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

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

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

二、并行的两个重要定律

Amdahi定律

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越低,加速比也就越高

Gustafson定律

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() 方 法

本文参与 腾讯云自媒体分享计划,分享自作者个人站点/博客。
原始发表:2018年12月15日,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 一、线程并行相关概念
    • 同步(Synchronous)和异步(Asynchronous)
      • 并发(Concurrency)和并行(Parallelism)
        • 临界区
          • 阻塞(Blocking)和非阻塞(Non-Blocking)
            • 饥饿(Starvation)、死锁(Deadlock)和活锁(Livelock)
            • 二、并行的两个重要定律
              • Amdahi定律
                • Gustafson定律
                • 三、多线程的特性
                  • 原子性
                    • 可见性
                      • 有序性
                      领券
                      问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档