Java-锁相关

朴灿烈づ我的快乐病毒、 2023-10-10 17:42 22阅读 0赞

> ### 线程不安全的原因 ###
> 
> 1.调度器随机调度,抢占式执行(无能为力)
> 
> 举个例子 有一个int变量 叫count 就俩线程同时count++一万次 结果应该为两万 可多次运行程序 这结果每次都不一样(而且小于2w) 是为什么呢
> 
> 因为count++这行代码是分三步运行的
> 
> load 把数据读到cpu
> 
> add 在cpu寄存器实现加法运算
> 
> save 把运算完成的数据存回cpu
> 
> 如果count为0 load(线程1) load(线程2) add(线程1) add(线程2) save(线程1) save(线程2) 他们load的时候count都为0 而且save的时候都把1存在了内存中 所以两次运算 count也只是1
> 
> 2.多个线程修改一个变量(部分规避)
> 
> 3.修改操作不是原子性的(锁操作)
> 
> 4.内存可见性(锁操作)
> 
> 5.指令重排序
> 
> 后两种都是编译器/JVM/操作系统 误判了的原因 把不该优化的地方给优化了 就导致了bug的出现
> 
> 可以通过volatile关键字解决(相当于禁止了编译器进行优化)

> ### synchronized加锁的几种方式 ###
> 
> 先说下加锁的意义,加锁就是:这个被加锁的线程结束,,其他线程才能拿到该资源进行执行线程!
> 
> 还是用上面的count++操作举例子,如果这个线程被加锁了,那它的运行逻辑就是
> 
> (线程1) load add save (线程2)load add save 也就是说只有当这个线程1完成之后,才能运行线程2
> 
>     public class Main {	
>     	 private static int a = 0;
>     	 private static int b = 0;
>     	 private static final int count = 10_0000;
>     	public synchronized static void increase(){
>             for (int i = 0; i < count; i++) {
>                 a++;
>             }
>         }
>     	public static void increase1(){
>             for (int i = 0; i < count; i++) {
>                 b++;
>             }
>         }
>     	 public static void main(String[] args)throws InterruptedException{
>                   Thread t1 = new Thread(()->{
>                 	  increase();
>                 	  increase1();
>                   });
>                   Thread t2 = new Thread(()->{
>                 	  increase();
>                 	  increase1();
>                   });
>                   t1.start();
>                   t2.start();
>                   t1.join();
>                   t2.join();
>                   System.out.println("a="+a);
>                   System.out.println("b="+b);
>     	    }
>     }
> 
> (要加join main也是一个线程(主线程) 不加join的话 它会在start之后 运行打印)
> 
> ![aa0ea45288de4b34a23c36b0dcb26cf3.png][]
> 
> 我们可以看出 加锁的方法 运行正确了 没加锁的方法就不对
> 
> 1. 修饰普通方法 相当于对this加锁
> 
> Public synchronized void increase()\{
> 
> 代码块
> 
> \}
> 
> 2.修饰静态方法,相当于对类对象加锁
> 
> Public synchronized static void increase()\{
> 
> 代码块
> 
> \}
> 
> 3.修饰代码块
> 
> public void method()\{
> 
> Synchronized(this)\{
> 
> 代码块\}
> 
> \}
> 
> 这个this是一个参数,是指对某个对象加锁,可以以实例对象,或者.class作为参数

> ### wait和notify ###
> 
> #### wait ####
> 
> 调用wait的线程会进入阻塞等待状态,同时会释放锁(所以wait要和synchronized搭配使用)
> 
> 进入调用wait后的流程
> 
> 1.释放锁
> 
> 2.等待通知(notify)
> 
> 3.当通知到达之后 就会被唤醒 并且尝试重新获取锁
> 
> #### notify ####
> 
> 唤醒处于wait状态的线程(也要和synchronized搭配使用)
> 
> #### 举个例子 ####
> 
>     ublic static void main(String[] args)throws InterruptedException{
>                   Object lock = new Object();
>                   Thread t1 = new Thread(()->{
>                 	  synchronized (lock) {		  
>                     	  try {
>                     		System.out.println("准备调用wait");
>     						lock.wait();
>     						System.out.println("调用结束");
>     					} catch (InterruptedException e) {
>     						e.printStackTrace();
>     					}                	  
>     				}	  
>                   });
>                   t1.start();
>                   System.out.println("准备notify");
>                   synchronized (lock) {
>                 	  lock.notify();
>                   }     
>                   System.out.println("notify结束");
>                  
>     	    }
> 
> 运行结果为:
> 
> ![1a87ca579551417096a89a912c5dd642.png][]
> 
> 我们可以看到是在notify结束之后才输出调用结束,也就是notify之后wait的线程才可以继续运行
> 
> 可是为什么准备notify是在准备调用wait之前呢,明明t1.start()是在打印准备notify之前调用的,
> 
> 因为main本身也是一个线程(主线程),在t1线程运行的时候主线程也在运行,打印notify又没被加锁
> 
> 所以他们的调度顺序就是随机的了
> 
> 更极端的情况:
> 
> ![665b27147b1242d3bc4f83bb702200dc.png][]
> 
> 我们可以看到"调用结束"甚至没被输出,主线程都运行结束了,都没调度到t1线程的输出"调用结束",为了防止这种情况,可以加一个join,在主线程的最后加join,有效防止这种情况发生
> 
> 顺便说下synchronized括号里面的参数和调用notify的对象必须是一个 否则会报错
> 
> 就像这个写法:
> 
> ![0dba50d93b6e4a528a650f99e79a749d.png][]
> 
> notify和wait应该在不同的线程中,因为这个线程wait了只能让其他线程notify(唤醒它)
> 
> 如果有多个线程被wait,那notify会随机唤醒其中一个(notifyall可以唤醒全部线程)(同一个(被)锁对象),

> #### 同步和异步 ####
> 
> 同步 调用者自己来负责获取调用结果
> 
> 异步 调用者自己不负责 被调用者主动推送

> ### 常见锁策略 ###
> 
> #### 乐观锁&悲观锁 ####
> 
> 乐观锁:乐观的认为操作数据的时候非常乐观，认为别人不会同时修改数据，因此乐观锁默认是不会上锁的，只有在执行更新的时候才会去判断在此期间别人是否修改了数据，如果别人修改了数据则放弃操作，否则执行操作。
> 
> 悲观锁:操作数据的时候比较悲观，认为别人一定会同时修改数据，因此悲观锁在操作数据时是直接把数据上锁，直到操作完成之后才会释放锁，在上锁期间其他人不能操作数据。
> 
> 读取频繁使用乐观锁(多线程读 不设计修改 线程安全)，写入频繁使用悲观锁
> 
> synchronized既是悲观锁,又是乐观锁,当前锁冲突概率不大 以乐观锁方式运行,一旦发现冲突概率大了 就以悲观锁方式运行
> 
> #### 普通互斥锁&读写锁 ####
> 
> 普通互斥锁 两个加锁操作会发生竞争
> 
> 读写锁:把加锁操作细化了加锁分成了 加读锁 加写锁
> 
> a尝试加读锁
> 
> b尝试加读锁
> 
> ab不产生竞争 锁相当于没加
> 
> a尝试加读锁
> 
> b尝试加写锁 ab产生竞争 和普通锁没区别
> 
> synchronized是普通互斥锁
> 
> #### 重量级锁&轻量级锁 ####
> 
> 重量级锁 锁开销大 做的工作比较多
> 
> 轻量级锁 锁开销小 做的工作比较少
> 
> 悲观锁经常是重量级锁
> 
> 乐观锁经常是轻量级锁（不绝对）
> 
> sychronized是自适应的锁 既是重量级又是轻量级
> 
> #### 公平锁&非公平锁 ####
> 
> 符合先来后到的规则才是公平,非公平锁 机会均等反而是不公平的
> 
> synchronized是非公平锁
> 
> #### 自旋锁&挂起等待锁 ####
> 
> 自旋锁(轻量级锁的具体实现 乐观锁)
> 
> 当发现冲突的时候 不会挂起等待 会迅速再来尝试看这个锁能不能获取到
> 
> 1.一旦锁被释放 就可以第一时间获取到
> 
> 2.如果锁一直不释放 就会消耗大量的CPU
> 
> 挂起等待锁 (重量级锁 悲观锁)
> 
> 发现锁冲突就挂起等待
> 
> 1.一旦锁被释放不能第一时间获取到
> 
> 2.在锁被其他线程占用的时候 会放弃cpu资源
> 
> sychronized作为轻量级锁时 内部是自旋锁
> 
> sychronized作为重量级锁时 内部是挂起等待锁
> 
> #### 可重入锁&不可重入锁 ####
> 
> 可重入锁:在内部记录这个锁是哪个线程获取到的 如果发现当前加锁的线程和持有锁的线程是用一个 则不挂起等待
> 
> 同时在内部引入计数器 记录第几次加锁控制什么时候释放锁(不会提前释放锁)
> 
> 不可重入锁:
> 
> private synchronized static void func()\{
> 
> func1();
> 
> \}
> 
> private synchronized static void func1()\{
> 
> \}
> 
> 这个func已经获取到锁了 然后func1需要获取锁才能运行 但是func1不运行完func还获取不到 就死锁了

[aa0ea45288de4b34a23c36b0dcb26cf3.png]: https://img-blog.csdnimg.cn/aa0ea45288de4b34a23c36b0dcb26cf3.png
[1a87ca579551417096a89a912c5dd642.png]: https://img-blog.csdnimg.cn/1a87ca579551417096a89a912c5dd642.png
[665b27147b1242d3bc4f83bb702200dc.png]: https://img-blog.csdnimg.cn/665b27147b1242d3bc4f83bb702200dc.png
[0dba50d93b6e4a528a650f99e79a749d.png]: https://img-blog.csdnimg.cn/0dba50d93b6e4a528a650f99e79a749d.png