JUC并发编程02——锁

双非鼠不想输

已于 2024-09-12 15:07:46 修改

阅读量817

点赞数 16

分类专栏： JUC并发编程文章标签： java 开发语言

于 2023-12-10 15:46:31 首次发布

本文链接：https://blog.csdn.net/qq_62767608/article/details/134866082

版权

JUC并发编程专栏收录该内容

11 篇文章 0 订阅

订阅专栏

2.2从字节码角度分析 synchronized 实现

一.乐观锁和悲观锁

悲观锁

认为自己在使用数据的时候一定有别的线程来修改数据，因此在获取数据的时候会先加锁，确保数据不会被别的线程修改。
synchronized关键字和Lock的实现类都是悲观锁。

适用场景：适合写操作多的场景，先加锁可以保证写操作时数据正确。

乐观锁

乐观锁认为自己在使用数据时不会有别的线程修改数据，所以不会添加锁，只是在更新数据的时候去判断之前有没有别的线程更新了这个数据。
如果这个数据没有被更新，当前线程将自己修改的数据成功写入。如果数据已经被其他线程更新，则根据不同的实现方式执行不同的操作。
乐观锁在Java中是通过使用无锁编程来实现，最常采用的是CAS算法，Java原子类中的递增操作就通过CAS自旋实现的。

适用场景：适合读操作多的场景，不加锁的特点能够使其读操作的性能大幅提升。

实现方式

乐观锁一般有两种实现方式：

采用版本号机制
CAS（Compare-and-Swap，即比较并替换）算法实现

二.synchronized 锁

2.1synchronized 锁的内容

对于普通同步方法，锁的是调用当前方法的对象，通常指 this 。并且该对象中所有的普通同步方法用的都是同一把锁。也就是说如果一个实例对象的普通同步方法获取锁后，该实例对象的其他普通同步方法必须等待获取锁的方法释放锁后才能获取锁。（对象锁）
对于静态同步方法，锁的是当前类的Class对象，如 Phone.class 唯一的一个模板。一旦一个静态同步方法获取锁后，其他的静态同步方法都必须等待该方法释放锁后才能获取锁。（类锁）
对于同步代码块，锁的是 synchronized 括号内的对象。

《阿里巴巴开发手册》中提到：“高并发时，同步调用应该去考量锁的性能损耗。能用无锁数据结构，就不要用锁；能锁区块，就不要锁整个方法体；能用对象锁，就不要用类锁。 ”

注意：具体实例对象 this 和 Class对象，这两把锁是两个不同的对象，所以静态同步方法与普通同步方法之间是不会有竞态条件的

2.2从字节码角度分析 synchronized 实现

synchronized 同步代码块

synchronized的底层实现原理

synchronized作用在代码块时，实现使用的是 monitorenter 和 monitorexit 指令

这里有一个 monitorenter，却有两个 monitorexit 指令的原因是：JVM 要保证每个 monitorenter 必须有与之对应的 monitorexit，monitorenter 指令被插入到同步代码块的开始位置，而 monitorexit 需要插入到方法正常结束处和异常处两个地方，这样就可以保证抛异常的情况下也能释放锁。

可以把执行 monitorenter 理解为加锁，执行 monitorexit 理解为释放锁，每个对象维护着一个记录着被锁次数的计数器。未被锁定的对象的该计数器为 0，我们来具体看一下 monitorenter 和 monitorexit 的含义：

monitorenter

执行 monitorenter 的线程尝试获得 monitor 的所有权，会发生以下这三种情况之一：

如果该 monitor 的计数为 0，则线程获得该 monitor 并将其计数设置为 1。然后，该线程就是这个 monitor 的所有者。
如果线程已经拥有了这个 monitor ，则它将重新进入，并且累加计数。
如果其他线程已经拥有了这个 monitor，那个这个线程就会被阻塞，直到这个 monitor 的计数变成为 0，代表这个 monitor 已经被释放了，于是当前这个线程就会再次尝试获取这个 monitor。

monitorexit

monitorexit 的作用是将 monitor 的计数器减 1，直到减为 0 为止。代表这个 monitor 已经被释放了，已经没有任何线程拥有它了，也就代表着解锁，所以，其他正在等待这个 monitor 的线程，此时便可以再次尝试获取这个 monitor 的所有权。

synchronized 普通同步方法

可以看出，被 synchronized 修饰的方法会有一个 ACC_SYNCHRONIZED 标志。当某个线程要访问某个方法的时候，会首先检查方法是否有 ACC_SYNCHRONIZED 标志，如果有则需要先获得 monitor 锁，然后才能开始执行方法，方法执行之后再释放 monitor 锁。

synchronized 静态同步方法

ACC_STATIC，ACC_SYNCHRONIZED 访问标志区分该方法是否静态同步方法。

总结

同步代码块和同步方法这两种同步方式本质上没有区别，只是方法的同步是一种隐式的方式来实现，无需通过字节码来完成。两个指令的执行是JVM通过调用操作系统的互斥原语mutex来实现，被阻塞的线程会被挂起、等待重新调度，会导致“用户态和内核态”两个态之间来回切换，对性能有较大影响。

2.3为什么每个对象都能成为锁

Java中的每个对象都派生自Object类，而每个Java Object在JVM内部都有一个native的C++对象oop/oopDesc进行对应。线程在获取锁的时候，实际上就是获得一个监视器对象 (monitor)，monitor可以认为是一个同步对象，所有的Java对象是天生携带monitor。因此，任何一个对象都可以成为一个锁。这也是为什么我们常说的“Java中每个对象都持有一把锁”，这是synchronized实现同步的基础。

三.公平锁和非公平锁

公平锁：多个线程按照申请锁的顺序去获得锁，线程会直接进入队列去排队，永远都是队列的第一位才能得到锁。
- 优点：所有的线程都能得到资源，不会饿死在队列中。
- 缺点：吞吐量会下降很多，后来的线程全部会被挂起并进入等待队列。
```
Lock lock = new ReentrantLock(true);//true 表示公平锁,先来先得
```
非公平锁：多个线程去获取锁的时候，会直接去尝试获取，获取不到，再去进入等待队列，如果能获取到，就直接获取到锁。synchronized就是非公平锁。
- 优点：非公平锁减少了线程挂起的几率，后来的线程有一定几率逃离被挂起的开销，整体的吞吐效率会高点。
- 缺点：可能导致队列中间的线程一直获取不到锁或者长时间获取不到锁，导致饿死。
```
Lock lock = new ReentrantLock(false)://false 表示非公平锁，后来的也可能先获得锁
Lock lock = new ReentrantLock();//默认非公平锁
```

为什么线程切换会导致用户态与内核台的切换？

因为线程的调度是在内核态运行的，而线程中的代码是在用户态运行。

公平锁执行流程