高龄白菜JAVA学习第十二天（JUC|死锁|可重入锁|线程协作）-CSDN博客

本文链接：https://blog.csdn.net/mangosea/article/details/118559034

一、JUC
1.不安全数组：

2.安全数组：

二、死锁
一个同步块同时拥有两个对象的锁时，就有可能发生死锁问题
在这里插入图片描述

产生死锁的四个必要条件：
1.互斥条件：每个资源每次只能被一个进程使用
2.请求与保持条件：一个进程因请求资源而阻塞时，对已获得的资源保持不放
3.不剥夺条件：进程已获得的资源，在未使用完之前，不能强行剥夺
4.循环等待条件：若干进程之间形成一种头尾相接的循环等待资源关系
只要有一个条件被破坏，则死锁不成立

可重入锁
在这里插入图片描述
synchronized和lock的对比
1.lock是显示锁，手动开关，synchronized是隐式锁，除了作用域自动释放
2.lock只有代码块锁，而synchronized有代码块锁和方法锁
3.使用lock锁，JVM将花费较少的时间调度线程，性能好，扩展性好（提供更多子类）
4.使用优先顺序:lock>同步代码块>同步方法

四、线程协作
1.管程法
生产者消费者
在这里插入图片描述

对图中总结的详细说明：
对于数组下标越界问题的解释：
1、这个例子只适用于一个生产者一个消费者的情况，因为消费者wait()释放对象锁权限让出CPU，只会是那唯一的生产者重新拿到锁权限进行生产，这样的话不消费就生产，不生产就消费，是不会出现下标越界的，而如果不止一个消费者就会有下标越界的问题。原因如2；
2、首先要说明，wait()表示持有对象锁的线程准备释放对象锁权限和让出 cpu 资源并进入等待状态。如果有多个消费者，比如X1，X2，X3，假如此时X1，X2，X3都处于wait状态，这时容量为0了生产者拿到锁，生产者生产了1个资源让出锁，X1拿到锁消费完之后容量又刚好为0，然后X1释放锁notifyAll通知JVM去唤醒所有竞争Container对象锁的线程，如果这个锁被X2拿到，那么就会导致0–出现数组下标越界的问题，解决方案暂时只想到把消费的if(index =0)换成while就是让消费者线程被唤醒的时候不要立刻执行下面的代码，而是再去判断当前容量。