线程---JUC

最新推荐文章于 2023-01-11 21:35:44 发布

箱水母

最新推荐文章于 2023-01-11 21:35:44 发布

阅读量115

点赞数

分类专栏：学习笔记 # 线程文章标签： java spring

本文链接：https://blog.csdn.net/poppy_poppy/article/details/120344180

版权

学习笔记同时被 2 个专栏收录

54 篇文章 0 订阅

订阅专栏

线程

4 篇文章 0 订阅

订阅专栏

JUC

Java真的可以开启线程吗？开不了的，底层是用native关键词修饰，调用本地实现。
并发编程的本质: 充分利用CPU的资源
请添加图片描述

Callable

请添加图片描述
普通的线程代码，之前都是用的thread或者runnable接口。
但是相比于callable来说，thread没有返回值，且效率没有callable高。
与Runnable区别：
1、可以有返回值
2、可以抛出异常
3、方法不同，分别是call()和run()

public class CallableDemo {
    public static void main(String[] args) throws ExecutionException, InterruptedException {
        MyCallable myCallable = new MyCallable();
        // 需要适配类和Thread建立关联
        FutureTask futureTask = new FutureTask(myCallable);
 
        new Thread(futureTask, "CallableDemo").start();//简写
        String str = (String) futureTask.get();
        System.out.println(str);
    }
}
 
class MyCallable implements Callable<String> {
 
    @Override
    public String call() throws Exception {
        System.out.println("MyCallable .call");
        return "abc";
    }
}

Runnable

public class ThreadDemo {
    public static void main1(String[] args) {
        MyThread myThread = new MyThread();
        myThread.start();
    }

    public static void main(String[] args) {
        MyRunnable myRunnable = new MyRunnable();
        Thread thread = new Thread(myRunnable);
        thread.start();

        String name = Thread.currentThread().getName();
        System.out.println(name); // main
        for (int i = 0; i < 10000; i++) {
            System.out.println(name + " : " + i);
        }
    }
}

Lock锁

请添加图片描述
ReentrantLock构造器

true是公平锁，false是非公平锁
为什么默认是非公平锁，如果有两个线程一个3s一个3h，3s在3h后面，那样3s的虽然执行时间很短也要等3h才能执行。

synchronized和lock（ReentrantLock）锁的区别

1、synchronized内置的java关键字,Lock是一个java类
2、synchronized无法判断获取锁的状态, Lock可以判断是否获取到了锁
3、synchronized会自动释放锁,Lock必须要手动释放锁!如果不是释放锁,会产生死锁
4、synchronized 线程1(获得锁),线程2(等待); Lock锁就不一定会等待下去，lock.tryLock()可以尝试去获取锁，不会一直等待，等不到就结束。
5、synchronized 可重入锁,不可以中断的,非公平的; Lock锁,可重入的,可以判断锁,非公平(可自己设置);
6、synchronized 适合锁少量的代码同步问题,Lock 适合锁大量的同步代码

虚假唤醒问题

原因

以两个加法线程Inc、Inc2举例：
1、比如Inc先执行，执行时调用了wait方法，那它会等待，此时会释放锁。
　那么线程Inc2获得锁并且也会执行wait()方法，且释放锁，同时两个加线程一起进入等待状态，等待被唤醒。
2、此时减线程中的某一个线程执行完毕并且唤醒了这俩加线程（notifyAll），那么这俩加线程不会一起执行，其中Inc获取了锁并且加1，执行完毕之后Inc2再执行。
如果是if的话，那么Inc修改完num后，Inc2不会再去判断num的值，直接会给num+1,如果是while的话，Inc执行完之后，Inc2还会去判断num的值，因此就不会执行。
上述情况称为：虚假唤醒
请添加图片描述

问题解决：将 if 改为 while

while时，只要是1就会一直等待，但是if只判断一次，之后无效。

形象的例子：当一个条件满足时，很多线程都被唤醒了，但是只有其中部分是有用的唤醒，其它的唤醒都是无用功。
比如说买货，如果商品本来没有货物，突然进了一件商品，这是所有的线程都被唤醒了，但是只能一个人买，所以其他人都是假唤醒，获取不到对象的锁。

读写锁 ReadWriteLock

ReadWriteLock 接口
所有已知实现类： ReentrantReadWriteLock
1、读：可多条线程同时获取数据
2、写：只能单条线程写入

独占锁（写锁）一次只能被一个线程占用
共享锁（读锁）多个线程可以同时占用
ReadWriteLock:
读-读可以共存
读-写不能共存
写-写不能共存

Volatile

Volatile是Java虚拟机提供的轻量级同步机制
1 保证可见性，
可见性就是当一个线程修改一个共享变量时，另外一个线程能读到这个修改的值。
2 不保证原子性，
不保证原子性是指：
private volatile static int num=0;
public static void add() {
num++;
}
num++操作不是原子性(++不是原子操作)，可能多个线程同时操作。
解决方法：我们可以加synchronized
public synchronized static void add() {
num++;
}
3 禁止指令重排，
指令重排是指在程序执行过程中,为了提高性能, 编译器和CPU可能会对指令进行重新排序。

CAS（Compare and swap）

比较并交换
CAS 是现代操作系统，解决并发问题的一个重要手段。

CAS操作包括了3个操作数

1、需要读写的内存位置(V)
2、进行比较的预期值(A)
3、拟写入的新值(B)

CAS操作逻辑

如果内存位置V的值等于预期的A值，则将该位置更新为新值B，否则不进行任何操作。
许多CAS的操作是自旋的：如果操作不成功，会一直重试，直到操作成功为止。

既然CAS包含了Compare和Swap两个操作，它又如何保证原子性呢？

CAS是由CPU支持的原子操作，其原子性是在硬件层面进行保证的。

为什么需要AtomicInteger原子操作类？

在Java中自增i++操作不是原子操作，它实际上包含三个独立的操作：
（1）读取i值；
（2）加1；
（3）将新值写回i
因此，如果并发执行自增操作，可能导致计算结果的不准确。
对于Java中的运算操作，例如自增或自减，若没有进行额外的同步操作，在多线程环境下就是线程不安全的。
明显，这个操作不具备原子性，多线程并发共享这个变量时必然会出现问题。
J.U.C 并发包提供了：
1、AtomicBoolean
2、AtomicInteger
3、AtomicLong

总结

CAS:比较当前工作内存(线程)中的值和主内存中的值，如果这个值是期望的，那么则执行操作，如果不是，就一直循环
优点：好处是不用切换线程状态，因为切换线程状态性能消耗比较大
缺点：
1：由于底层是自旋锁，循环会浪费时间
2：因为是底层的cpu操作，一次只能保证一个共享变量的原子性

公平锁、非公平锁

公平锁：不能插队，先来后到
非公平锁：可以插队，比如有些线程执行时间很短，但是也需要等待拿到锁的线程执行完（3h，3s），synchronized和lock默认都是非公平锁。

可重入锁

可重入锁，也叫做递归锁，是指在一个线程中可以多次获取同一把锁，
比如：一个线程在执行一个带锁的方法，该方法中又调用了另一个需要相同锁的方法，则该线程可以直接执行调用的方法【即可重入】，而无需重新获得锁；
所有的锁都是可重入锁，ReentrantLock 和synchronized 都是可重入锁。

自旋锁

不断地尝试，直到成功为止

死锁

死锁是一个互相争抢的过程，互相拥有对方需要的资源又不释放。请添加图片描述

死锁的发生必须具备以下四个必要条件。

1）互斥条件：指进程对所分配到的资源进行排它性使用，即在一段时间内某资源只由一个进程占用。如果此时还有其它进程请求资源，则请求者只能等待，直至占有资源的进程用毕释放。
2）请求和保持条件：指进程已经保持至少一个资源，但又提出了新的资源请求，而该资源已被其它进程占有，此时请求进程阻塞，但又对自己已获得的其它资源保持不放。
3）不剥夺条件：指进程已获得的资源，在未使用完之前，不能被剥夺，只能在使用完时由自己释放。
4）环路等待条件：指在发生死锁时，必然存在一个进程——资源的环形链，即进程集合{P0，P1，P2，···，Pn}中的P0正在等待一个P1占用的资源；P1正在等待P2占用的资源，……，Pn正在等待已被P0占用的资源。

只要打破四个必要条件之一就能有效预防死锁的发生。

乐观锁和悲观锁

乐观锁和悲观锁是两种思想，用于解决并发场景下的数据竞争问题。
乐观锁对应于生活中乐观的人总是想着事情往好的方向发展，悲观锁对应于生活中悲观的人总是想着事情往坏的方向发展。
这两种人各有优缺点，不能不以场景而说一种人好于另外一种人。

悲观锁

总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞直到它拿到锁（共享资源每次只给一个线程使用，其它线程阻塞，用完后再把资源转让给其它线程）。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。
Java中synchronized和ReentrantLock等独占锁就是悲观锁思想的实现。

乐观锁

总是假设最好的情况，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号机制和CAS算法实现。
乐观锁适用于多读的应用类型，这样可以提高吞吐量。
在Java中java.util.concurrent.atomic包下面的原子变量类就是使用了乐观锁的一种实现方式CAS实现的。

两种锁的使用场景

从上面对两种锁的介绍，我们知道两种锁各有优缺点，不可认为一种好于另一种
乐观锁适用于写比较少的情况下（多读场景），即冲突真的很少发生的时候，这样可以省去了锁的开销，加大了系统的整个吞吐量。
但如果是多写的情况，一般会经常产生冲突，这就会导致上层应用会不断的进行retry，这样反倒是降低了性能，所以一般多写的场景下用悲观锁就比较合适。

乐观锁常见的两种实现方式
1、版本号机制
一般是在数据表中加上一个数据版本号version字段，表示数据被修改的次数，当数据被修改时，version值会加一。当线程A要更新数据值时，在读取数据的同时也会读取version值，
在提交更新时，若刚才读取到的version值为当前数据库中的version值相等时才更新，否则重试更新操作，直到更新成功。
2、CAS算法
即compare and swap（比较与交换），是一种有名的无锁算法
一般情况下是一个自旋操作，即不断的重试。

箱水母

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
线程---JUC

JUCJUCCallableLock锁JUCJava真的可以开启线程吗？开不了的，底层是用native关键词修饰，调用本地实现。并发编程的本质: 充分利用CPU的资源Callable普通的线程代码，之前都是用的thread或者runnable接口。但是相比于callable来说，thread没有返回值，且效率没有callable高。与Runnable区别：1、可以有返回值2、可以抛出异常3、方法不同，分别是call()和run()public class CallableDemo
复制链接

扫一扫