3.10多线程

一.常见锁策略

1.悲观锁 vs乐观锁

体现在处理锁冲突的态度

①悲观锁:预期锁冲突的概率高

所以做的工作更多,付出的成本更多,更低效

②乐观锁:预期锁冲突的概率低

所以做的工作少,付出的成本更低,更搞笑

2.读写锁 vs 普通的互斥锁

①普通的互斥锁,只有两个操作 加锁和解锁

只有两个线程针对同一个对象加锁,就会产生互斥

②读写锁:有三个操作

针对读锁和读锁之间,是不存在互斥的关系--->因为多线程同时读一个变量,不会有线程安全的问题

读锁和写锁之间,写锁和写锁才需要互斥

而且很多场景中,都是读多写少

3.重量级锁 vs 轻量级锁

是为了处理锁冲突的结果

重量级锁 做了更多的事情,开销大,轻量级锁反之亦然

大多数情况下,悲观锁一般都是重量级锁,乐观锁一般都是轻量级锁

比如: 在使用的锁中,如果锁是基于内核的一些功能来实现的(比如调用了操作系统提供的mutex接口).一般认为这是重量级锁

如果锁是纯纯用户态实现的,一般认为这是轻量级锁,因为用户态的代码更可靠,也更高效

4.挂起等待锁 vs 自旋锁

①挂起等待锁:通过内核的一些机制来实现的.往往比较中 [重量级锁的一种典型实现]

②自旋锁 : 往往是通过用户态代码来实现的,往往比较轻,[轻量级锁的一种典型实现]\

5.公平锁 vs 非公平锁

公平锁:多个线程在等待一把锁的时候谁是先来的,谁就能先获取到这个锁(遵守先来后到

非公平锁:多个线程在等待一把锁的时候不遵守先来后到,每个等待的线程获取到锁的概率是均等的

对于操作系统来说->线程之间的调度是随机的(机会是均等的) .操作系统提供的mutex这个锁.就是属于非公平锁

6.可重入锁 vs 不可重入锁

可以嵌套加锁,就是可重入锁,会死锁的就是不可重入锁

7.synchronized(面试

1)即是一个乐观锁.也是一个悲观锁(根据锁竞争的激烈程度,自适应)

2)不是读写锁,只是一个普通互斥锁

3)既是一个轻量级锁,也是一个重量级锁,(根据锁竞争的激烈程度,自适应)

4)非公平锁 5)可重入锁

二.CAS

compare(比较) and swap(交换)

1.定义

CAS锁:拿着寄存器或者/某个内存的值和另外一个内存的值进行比较,如果值相同了,就交换

伪代码

CAS:提供一个单纯的CAS指令,通过这一条指令,就完成上述伪代码描述的过程

CAS指令:如果上述伪代码的过程只用一条做完,就是原子性,这个时候就是线程安全了

2.作用

1)基于CAS能够实现原子类

(java标准库里提供了一组原子性,针对常用的int.long,,int[]进行了封装,基于cas方式修改,并且线程安全

这段代码是不存线程安全的问题

基于CAS实现的++操作

因为这里既能保证线程安全,又能比synchronized高效

synchronized会涉及到锁的竞争,又要涉及线程的阻塞等待

这里的oldvalue变量,实际实际上可能使用一个寄存器来存的

这个赋值操作就相当于把数据从内存读到寄存器中(load

判定一下当前内存的值是不是和刚刚寄存器取到的值一直

如果判定成功,那就把value设为oldvalue+1.并返回true 循环结束

如果判定失败,继续下次循环,返回true;下次循环还是要先读一下value

这两行代码之间,很有可能有其他线程修改了value的值

为什么上述++操作线程安全

load

cas

2).基于CAS实现自旋锁

自旋锁是一个轻量级锁,也可以视为一个乐观锁

这把锁虽然没能够立即拿到,预期很快就能拿到(假设锁冲突不激烈)

3.ABA问题

1)定义

CAS中的关键就是先比较再交换

比较其实在比较当前值和旧值是否相同

把这两个值相同,就视为中间没有发生改变

但是这句话有漏洞,可能当前值和旧值相同的情况是因为变了然后又变回来了, 这就是ABA

2.案例

举例:ABA产生的BUG

假设小红账户余额 100 他想要取50

当按下取钱操作的时候,机器卡了一下,小红一紧张多按了一下取款

这就相当于 一次取钱操作 执行了两遍 (两个线程,并发的去执行这个取钱操作)

预期是只能取成功一次

如果基于CAS来实现的话

本来应该没问题

第二个线程再比较的时候就会发现,读到的100和原本的50不一样,就会不操作了

但是在取款的一瞬间,小红额度朋友给他转账了50.这个时候就会触发的ABA问题

这个时候第二个线程就会发现还是100.于是又扣了50

3)解决方法

引入版本号

这个版本号只能变大,修改变量的时候,比较的不是变量而是比较版本号

当引入版本号以后,t2再次尝试进行这里的比较版本操作

就会发现版本的旧值和当前的值并不匹配,就直接放弃修改

或者加入时间戳

看当前读到的内存改变的时间戳有没有变化

三.synchronized锁优化机制

只考虑1.8情况

1.锁膨胀/锁升级

体现了synchronized能够"自适应"这样的能力

偏向锁:并不是真的加锁,只是做了个标记.带来的好处就是后续没有竞争额时候,就避免了加锁解锁的开销

比如在大学校园里,大家都很讲素质,所以我的自行车都不锁->我只是在上面刻了我的名字做个标记

但是有一天好几个人的自行车都丢了,.开始有竞争的现象.我就开始加锁.进入轻量级锁

2.锁粗化/锁细化

此处的粗细指的是"锁的粒度"---->加锁代码涉及到的范围,范围越大,就认为锁的粒度越粗.反之亦然

锁粒度细 并发高

锁粒度粗.加锁解锁的开销就小

但是编译器会优化,如果某个地方代码所太细了,就会进行自动粗化

如果加锁之间间隔少(中间的代码少) 就很可能触发这个优化

比如:我给老师打电话,让他帮我请假.然后又打电话说我要出校,然后紧接着又打电话说我想借钱

每次给老师打电话都是给老师加锁,老师都不能接其他人的电话,加锁解锁开销大 粒度太细

于是可以粗化,我一次性说完.再挂电话

3.锁消除

有时候不小心加锁了

编译器发现这个锁没必要就会自动消除

比如StringBuffer Vector 在标准库里都进行了加锁操作

如果在单线程用到了上述的类,编译器会自动解锁.

四.java中的JUC

JUC ------java.util.concurrent

concurrent 并发的

1.Callable

是一个interface 也是一种创建线程的方式

因为Runnable 不太适合让线程计算一个结果

而如果用Callable就比较容易

    public static void main1(String[] args) throws InterruptedException {Result result=new Result();Thread t=new Thread(){@Overridepublic void run() {int sum=0;for (int i = 0; i < 100; i++) {sum+=i;}synchronized (result.locker){result.sum=sum;//如果不加锁额度话,这是一个写操作,可能会导致线程不安全的情况,需要加锁result.locker.notify();}}};t.start();synchronized (result.locker){while(result.sum==0){result.locker.wait();}}//加锁,直到赋值了才可以唤醒才可以往下执行System.out.println(result.sum);//这里还需要创建一个实例让他们的sum互相传}

    public static void main2(String[] args) {//构建一个类来描述任务Callable<Integer> callable=new Callable<Integer>() {@Overridepublic Integer call() throws Exception {int sum=0;for (int i = 0; i < 100; i++) {sum+=i;}return sum;}};//因为线程的构造方法不能识别callable 需要创建一个类来识别,FutureTask<Integer> task=new FutureTask<>(callable);Thread thread=new Thread(task);thread.start();//凭借task能执行//如果线程里的任务没执行完,task.get(就会一直阻塞,直到任务完成try {System.out.println(task.get());} catch (InterruptedException e) {e.printStackTrace();//这是任务没执行完阻塞} catch (ExecutionException e) {e.printStackTrace();//这是任务出错执行}}

2.ReentrantLock

可重入锁,注意synchronized也是可重入锁

1)基础用法

lock()

unlock()

把加锁和解锁两个操作给分开了

这中分开额度做法不太好,容易出现死锁

当出现多个线程竞争同一把锁的时候就会阻塞

2)与synchronized区别(面试)

1.synchronized是一个关键字(背后的逻辑是由JVM实现的也就是c++代码)

ReentrantLock是标准库里的一个类 背后的逻辑是java代码写的

2,synchronized不需要手动释放锁,出代码块,锁自动释放,

ReentrantLock必须要手动释放锁,要谨防忘记释放

3.synchronized是一个非公平锁

ReentrantLock提供了非公平锁和非公平锁 在构造方法中,指定参数来 默认是false

4.synchronized如果竞争锁额度时候失败,就会阻塞等待

ReentrantLock不仅可以阻塞等待,还可以trylock 失败了直接返回

5.synchronized衍生出来的等待机制,是wait notify 功能是相对有限的

ReentrantLock衍生出来的等待机制,是Condition.功能比较丰富

3.Semaphore

信号量 是一个更广义的锁

是锁里的一种特殊情况,叫做二元信号量

这个牌子就是信号量,描述了可用资源的个数

每次申请一个可用资源,计数器就-1(也就是P操作 ->acquire 申请

每次释放一个可用资源 计数器就+1 也就是V操作 ->release 释放

当信号量的计数为0 再次进行p操作,就会阻塞等待

锁就可以视为二元信号量.可用资源就一个,计数器的取值非0即1

4.CountDownLatch

终点线

countdown 给每个线程里面调用就表示到达终点

await 给等待线程去调用 所有任务都到达终点了.awit就阻塞返回 就表示任务完成

当所有的选手都冲过终点才认为是比赛结束

多线程下载

    public static void main(String[] args) throws InterruptedException {CountDownLatch countDownLatch=new CountDownLatch(10);//表示有10个选手for (int i = 0; i < 10; i++) {Thread t =new Thread(()->{try {Thread.sleep(3000);System.out.println(Thread.currentThread().getName()+"已到达");countDownLatch.countDown();//记录次数} catch (InterruptedException e) {e.printStackTrace();}});t.start();}//当十个线程都执行完,await才停止阻塞countDownLatch.await();System.out.println("比赛结束");}

五.哈希表

HashMap本身是线程不安全的

1.HashTable->推荐

2.ConcurrentHashMap->不推荐

针对this加锁,只要有多个线程来访问HashTable,就会加锁

假设员工想请假,就得当面来申请,他好签字

由于公司里的人很多,很多人都要请假,这个时候大家都在老板门口排队,非常不方便

每个HashTable都只有一把锁

解决方法

ConcurrentHashMap

每个链表头加锁

1.面试问题-CconcurrentHashMap和HashTable的关系

1.ConcurrentHashTable只是减少了锁冲突,就让锁加到每个链表的头节点

2,ConcurrentHashMap只是针对写操作 读操作没加锁

3,ConcurrentHashMap广泛使用CAS,

4,ConcurrentHashMap针对扩容,巧妙的化整为零