当前位置:首页 » 《休闲阅读》 » 正文

Java之线程篇六

10 人参与  2024年09月24日 18:01  分类 : 《休闲阅读》  评论

点击全文阅读


目录

CAS 

CAS伪代码

CAS的应用

实现原子类 

实现自旋锁

CAS的ABA问题

ABA问题导致BUG的例子 

相关面试题

synchronized原理

synchronized特性 

加锁过程

相关面试题

Callable

相关面试题

JUC的常见类

ReentrantLock

ReentrantLock 和 synchronized 的区别:

原子类

信号量

相关面试题


CAS 

CAS: 全称Compare and swap,字面意思:”比较并交换“,一个 CAS 涉及到以下操作:

我们假设内存中的原数据V,旧的预期值A,需要修改的新值B。
1. 比较 A 与 V 是否相等。(比较)
2. 如果比较相等,将 B 写入 V。(交换)
3. 返回操作是否成功。

CAS伪代码
下面写的代码不是原子的 , 真实的 CAS 是一个原子的硬件指令完成的 . 这个伪代码只是辅助理解 CAS 的工作流程。
boolean CAS(address, expectValue, swapValue) {   if (&address == expectedValue) {       &address = swapValue;       return true;   }   return false;}

CAS其实是一个cpu指令,单个的cpu指令,是原子的!!!

就可以使用CAS完成一些操作,进一步代替“加锁”;

基于CAS实现线程安全的方式也称为“无锁化编程”。

优点:保证线程安全,同时避免阻塞,影响效率;

缺点:代码会变复杂,不好理解;只能够适用特定场景,不如加锁方式更普遍。

CAS的应用
实现原子类 

标准库中提供了 java.util.concurrent.atomic 包, 里面的类都是基于这种方式来实现的. 
典型的就是 AtomicInteger 类. 其中的 getAndIncrement 相当于 i++ 操作.

伪代码实现

class AtomicInteger {    private int value;    public int getAndIncrement() {        int oldValue = value;        while ( CAS(value, oldValue, oldValue+1) != true) {            oldValue = value;       }        return oldValue;   }}
实现自旋锁

伪代码实现

public class SpinLock {    private Thread owner = null;    public void lock(){        // 通过 CAS 看当前锁是否被某个线程持有.         // 如果这个锁已经被别的线程持有, 那么就自旋等待.         // 如果这个锁没有被别的线程持有, 那么就把 owner 设为当前尝试加锁的线程.         while(!CAS(this.owner, null, Thread.currentThread())){       }   }    public void unlock (){        this.owner = null;   }}
CAS的ABA问题

ABA问题即:

假设有两个线程t1和t2,有一个共享变量num,初值为A,接下来t1想使用CAS把num改为Z,那么就需要先读取num的值,记录到oldNum变量中,然后使用CAS判断当前num的值是否为A,如果为A,则改为Z。

但是在t1执行上述操作之前,t2线程可能把num的值从A改为B,又从B改为A。

那么此时,线程t1无法区分当前这个变量始终是A,还是经历了一个变化过程。

ABA问题导致BUG的例子 

假设你要去ATM取款机取钱,余额有1000,要取款500,但是取款的时候ATM机卡了一下,所以你按了两下,假设ATM取款机按CAS方式工作,虽然你按了两次,但是你取出的是500,不过,如果恰巧这个时候有人给你转了500,这个时候,你按的第2下取款,使用CAS方式会发现余额还是1000,那么此时就会余额没有改变,你最后会取出1000.

解决方法:引入版本号等方式

给要修改的值, 引入版本号. 在 CAS 比较数据当前值和旧值的同时, 也要比较版本号是否符合预期. 
CAS 操作在读取旧值的同时, 也要读取版本号. 
真正修改的时候, 
如果当前版本号和读到的版本号相同, 则修改数据, 并把版本号 + 1.
如果当前版本号高于读到的版本号. 就操作失败(认为数据已经被修改过了).

相关面试题
1) 讲解下你自己理解的 CAS 机制 全称 Compare and swap, 即 "比较并交换". 相当于通过一个原子的操作, 同时完成 "读取内存, 比较是否相等, 修改内存" 这三个步骤. 本质上需要 CPU 指令的支撑

2) ABA问题怎么解决?

给要修改的数据引入版本号. 在 CAS 比较数据当前值和旧值的同时, 也要比较版本号是否符合预期. 
如果发现当前版本号和之前读到的版本号一致, 就真正执行修改操作, 并让版本号自增; 如果发现当前版本号比之前读到的版本号大, 就认为操作失败.

synchronized原理
synchronized特性 

1. 开始时是乐观锁, 如果锁冲突频繁, 就转换为悲观锁.
2. 开始是轻量级锁实现, 如果锁被持有的时间较长, 就转换成重量级锁. 
3. 实现轻量级锁的时候大概率用到的自旋锁策略
4. 是一种不公平锁
5. 是一种可重入锁
6. 不是读写锁

加锁过程

JVM 将 synchronized 锁分为 无锁、偏向锁、轻量级锁、重量级锁 状态。会根据情况,进行依次升级。 

1)偏向锁

第一个尝试加锁的线程, 优先进入偏向锁状态. 
偏向锁不是真的 "加锁", 只是给对象头中做一个 "偏向锁的标记", 记录这个锁属于哪个线程. 
如果后续没有其他线程来竞争该锁, 那么就不用进行其他同步操作了(避免了加锁解锁的开销)
如果后续有其他线程来竞争该锁(刚才已经在锁对象中记录了当前锁属于哪个线程了, 很容易识别当前申请锁的线程是不是之前记录的线程), 那就取消原来的偏向锁状态, 进入一般的轻量级锁状态. 
偏向锁本质上相当于 "延迟加锁" . 能不加锁就不加锁, 尽量来避免不必要的加锁开销. 
但是该做的标记还是得做的, 否则无法区分何时需要真正加锁.

2)轻量级锁

随着其他线程进入竞争, 偏向锁状态被消除, 进入轻量级锁状态(自适应的自旋锁). 
此处的轻量级锁就是通过 CAS 来实现.

通过 CAS 检查并更新一块内存 (比如 null => 该线程引用)
如果更新成功, 则认为加锁成功
如果更新失败, 则认为锁被占用, 继续自旋式的等待(并不放弃 CPU). 

3)重量级锁

如果竞争进一步激烈, 自旋不能快速获取到锁状态, 就会膨胀为重量级锁
此处的重量级锁就是指用到内核提供的 mutex . 
执行加锁操作, 先进入内核态. 
在内核态判定当前锁是否已经被占用
如果该锁没有占用, 则加锁成功, 并切换回用户态. 
如果该锁被占用, 则加锁失败. 此时线程进入锁的等待队列, 挂起. 等待被操作系统唤醒. 
经历了一系列的沧海桑田, 这个锁被其他线程释放了, 操作系统也想起了这个挂起的线程, 于是唤醒这个线程, 尝试重新获取锁. 

锁消除

编译器+JVM 判断锁是否可消除. 如果可以, 就直接消除。

例如:单线程环境下。 

锁粗化

一段逻辑中如果出现多次加锁解锁, 编译器 + JVM 会自动进行锁的粗化.  

相关面试题

1)什么是偏向锁?

偏向锁不是真的加锁 , 而只是在锁的对象头中记录一个标记 ( 记录该锁所属的线程 ). 如果没有其他线程参与竞争锁, 那么就不会真正执行加锁操作 , 从而降低程序开销 . 一旦真的涉及到其他的线程竞争, 再取消偏向锁状态 , 进入轻量级锁状态 .
Callable

Callable 和 Runnable 相对, 都是描述一个 "任务". Callable 描述的是带有返回值的任务, 
Runnable 描述的是不带返回值的任务. 
Callable 通常需要搭配 FutureTask 来使用. FutureTask 用来保存 Callable 的返回结果. 因为
Callable 往往是在另一个线程中执行的, 啥时候执行完并不确定. 
FutureTask 就可以负责这个等待结果出来的工作 

理解FutureTask

想象去吃麻辣烫 . 当餐点好后 , 后厨就开始做了 . 同时前台会给你一张 " 小票 " . 这个小票就是 FutureTask. 后面我们可以随时凭这张小票去查看自己的这份麻辣烫做出来了没 . 代码示例
import java.util.concurrent.Callable;import java.util.concurrent.ExecutionException;import java.util.concurrent.FutureTask;public class Demo30 {    public static void main(String[] args) throws ExecutionException, InterruptedException {        // 定义了任务.        Callable<Integer> callable = new Callable<Integer>() {            @Override            public Integer call() throws Exception {                int sum = 0;                for (int i = 0; i <= 1000; i++) {                    sum += i;                }                return sum;            }        };        // 把任务放到线程中进行执行.        FutureTask<Integer> futureTask = new FutureTask<>(callable);        Thread t = new Thread(futureTask);        t.start();        // 此处的 get 就能获取到 callable 里面的返回结果.        // 由于线程是并发执行的. 执行到主线程的 get 的时候, t 线程可能还没执行完.        // 没执行完的话, get 就会阻塞.        System.out.println(futureTask.get());    }}
相关面试题

介绍一下Callable是什么

Callable 是一个 interface . 相当于把线程封装了一个 "返回值". 方便程序猿借助多线程的方式计算结果. 
Callable 和 Runnable 相对, 都是描述一个 "任务". Callable 描述的是带有返回值的任务, 
Runnable 描述的是不带返回值的任务.
Callable 通常需要搭配 FutureTask 来使用. FutureTask 用来保存 Callable 的返回结果. 因为
Callable 往往是在另一个线程中执行的, 啥时候执行完并不确定. 
FutureTask 就可以负责这个等待结果出来的工作.

JUC的常见类

JUC,是java.util.concurrent的缩写。

ReentrantLock

可重入互斥锁. 和 synchronized 定位类似, 都是用来实现互斥效果, 保证线程安全. 
ReentrantLock 也是可重入锁. "Reentrant" 这个单词的原意就是 "可重入".

ReentrantLock的用法

lock(): 加锁, 如果获取不到锁就死等. 
trylock(超时时间): 加锁, 如果获取不到锁, 等待一定的时间之后就放弃加锁. 
unlock(): 解锁

ReentrantLock 和 synchronized 的区别:

synchronized 是一个关键字, 是 JVM 内部实现的(大概率是基于 C++ 实现). ReentrantLock 是标准库的一个类, 在 JVM 外实现的(基于 Java 实现). 
synchronized 使用时不需要手动释放锁. ReentrantLock 使用时需要手动释放. 使用起来更灵活, 但是也容易遗漏 unlock. 
synchronized 在申请锁失败时, 会死等. ReentrantLock 可以通过 trylock 的方式等待一段时间就放弃. 
synchronized 是非公平锁, ReentrantLock 默认是非公平锁. 可以通过构造方法传入一个 true 开启公平锁模式. 

更强大的唤醒机制. synchronized 是通过 Object 的 wait / notify 实现等待-唤醒. 每次唤醒的是一个随机等待的线程. ReentrantLock 搭配 Condition 类实现等待-唤醒, 可以更精确控制唤醒某个指定的线程.

// ReentrantLock 的构造方法public ReentrantLock(boolean fair) {    sync = fair ? new FairSync() : new NonfairSync();}

 如何选择使用哪个锁?

锁竞争不激烈的时候, 使用 synchronized, 效率更高, 自动释放更方便. 
锁竞争激烈的时候, 使用 ReentrantLock, 搭配 trylock 更灵活控制加锁的行为, 而不是死等. 
如果需要使用公平锁, 使用 ReentrantLock.

原子类

原子类内部用的是 CAS 实现,所以性能要比加锁实现 i++ 高很多。原子类有以下几个
AtomicBoolean
AtomicInteger
AtomicIntegerArray
AtomicLong
AtomicReference
AtomicStampedReference 

ExecutorService和Executors

ExecutorService 表示一个线程池实例. 
Executors 是一个工厂类, 能够创建出几种不同风格的线程池. 
ExecutorService 的 submit 方法能够向线程池中提交若干个任务. 

代码示例

ExecutorService pool = Executors.newFixedThreadPool(10);pool.submit(new Runnable() {    @Override    public void run() {        System.out.println("hello");   }});

Executors 创建线程池的几种方式:

newFixedThreadPool: 创建固定线程数的线程池
newCachedThreadPool: 创建线程数目动态增长的线程池.
newSingleThreadExecutor: 创建只包含单个线程的线程池. 
newScheduledThreadPool: 设定 延迟时间后执行命令,或者定期执行命令. 是进阶版的 Timer. 

Executors 本质上是 ThreadPoolExecutor 类的封装. 

信号量

信号量(Semaphore), 用来表示 "可用资源的个数". 本质上就是一个计数器.
Semaphore 的 PV 操作中的加减计数器操作都是原子的, 可以在多线程环境下直接使用. 

acquire 方法表示申请资源 (P 操作 ), release 方法表示释放资源 (V 操作 )

 代码示例

import java.util.concurrent.Semaphore;public class Demo24 {    public static void main(String[] args) throws InterruptedException {        Semaphore semaphore = new Semaphore(4);        semaphore.acquire();        System.out.println("P 操作");        semaphore.acquire();        System.out.println("P 操作");        semaphore.acquire();        System.out.println("P 操作");        semaphore.acquire();        System.out.println("P 操作");        semaphore.acquire();        System.out.println("P 操作");    }}

运行结果

相关面试题

1) 线程同步的方式有哪些?

synchronized, ReentrantLock, Semaphore 等都可以用于线程同步.

2) 为什么有了 synchronized 还需要 juc 下的 lock?

以 juc 的 ReentrantLock 为例, 
synchronized 使用时不需要手动释放锁. ReentrantLock 使用时需要手动释放. 使用起来更
灵活,
synchronized 在申请锁失败时, 会死等. ReentrantLock 可以通过 trylock 的方式等待一段时
间就放弃. 
synchronized 是非公平锁, ReentrantLock 默认是非公平锁. 可以通过构造方法传入一个
true 开启公平锁模式. 
synchronized 是通过 Object 的 wait / notify 实现等待-唤醒. 每次唤醒的是一个随机等待的
线程. ReentrantLock 搭配 Condition 类实现等待-唤醒, 可以更精确控制唤醒某个指定的线
程. 

3) AtomicInteger 的实现原理是什么?

基于 CAS 机制. 伪代码如下:  

class AtomicInteger {    private int value;    public int getAndIncrement() {         int oldValue = value;         while ( CAS(value, oldValue, oldValue+1) != true) {             oldValue = value;         }         return oldValue;   }}


点击全文阅读


本文链接:http://m.zhangshiyu.com/post/164119.html

<< 上一篇 下一篇 >>

  • 评论(0)
  • 赞助本站

◎欢迎参与讨论,请在这里发表您的看法、交流您的观点。

关于我们 | 我要投稿 | 免责申明

Copyright © 2020-2022 ZhangShiYu.com Rights Reserved.豫ICP备2022013469号-1