Java 并发 -- lock vs synchronizedvolatile（保证可见性和有序性）悲观锁 vs 乐观锁

Posted 2022-08-18 CodeJiao

1. lock vs synchronized

关于锁的概念不明白的可以参考这篇文章

要求

• 掌握 lock 与 synchronized 的区别
• 理解 ReentrantLock 的公平、非公平锁
• 理解 ReentrantLock 中的条件变量

三个层面

不同点

• 语法层面
  • synchronized 是关键字，源码在 jvm 中，用 c++ 语言实现
  • Lock 是接口，源码由 jdk 提供，用 java 语言实现
  • 使用 synchronized 时，退出同步代码块锁会自动释放，而使用 Lock 时，需要手动调用 unlock 方法释放锁
• 功能层面
  • 二者均属于悲观锁、都具备下面3个基本的功能
    • 互斥（多个线程争夺同一个锁，但是只有一个线程可以成功。其余的线程则陷入等待）
    • 同步（多个线程可以同时运行，但是如果其中的某个线程需要其他线程的结果，则该线程会一直等待其他线程返回结果才继续运行）
    • 锁重入（已经获得锁的线程，可以重复的去被锁住的资源加上多次锁）
  • Lock 提供了许多 synchronized 不具备的功能，例如获取等待状态（可以获取哪些线程被阻塞了）、公平锁、可打断、可超时、多条件变量
  • Lock 有适合不同场景的实现，如 ReentrantLock， ReentrantReadWriteLock
• 性能层面
  • 在没有竞争时，synchronized 做了很多优化，如偏向锁、轻量级锁，性能不赖
  • 在竞争激烈时，Lock 的实现通常会提供更好的性能

公平锁

• 公平锁的公平体现
  • 已经处在阻塞队列中的线程（不考虑超时）始终都是公平的，先进先出
  • 公平锁是指未处于阻塞队列中的线程来争抢锁，如果队列不为空，则老实到队尾等待
  • 非公平锁是指未处于阻塞队列中的线程来争抢锁，与队列头唤醒的线程去竞争，谁抢到算谁的
• 公平锁会降低吞吐量，一般不用

条件变量

• ReentrantLock 中的条件变量功能类似于普通 synchronized 的 wait，notify，用在当线程获得锁后，发现条件不满足时，临时等待的链表结构
• 与 synchronized 的等待集合不同之处在于，ReentrantLock 中的条件变量可以有多个，可以实现更精细的等待、唤醒控制。

---

2. volatile

要求

• 掌握线程安全要考虑的三个问题
• 掌握 volatile 能解决哪些问题

---

2.1 掌握线程安全要考虑的三个问题（原子性、可见性、有序性）

原子性

• 起因：多线程下，不同线程的指令发生了交错导致的共享变量的读写混乱
• 解决：用悲观锁或乐观锁解决，volatile 并不能解决原子性

可见性

• 起因：由于编译器优化、或缓存优化、或 CPU 指令重排序优化导致的对共享变量所做的修改另外的线程看不到
• 解决：用 volatile 修饰共享变量，能够防止编译器等优化发生，让一个线程对共享变量的修改对另一个线程可见

有序性

• 起因：由于JIT编译器优化、或缓存优化、或 CPU 指令重排序优化导致指令的实际执行顺序与编写顺序不一致
• 解决：用 volatile 修饰共享变量会在读、写共享变量时加入不同的屏障，阻止其他读写操作越过屏障，从而达到阻止重排序的效果
• 注意：
  • volatile 变量写加的屏障是阻止上方其它写操作越过屏障排到 volatile 变量写之下
  • volatile 变量读加的屏障是阻止下方其它读操作越过屏障排到 volatile 变量读之上
  • volatile 读写加入的屏障只能防止同一线程内的指令重排

---

2.2 volatile解决可见性、有序性

volatile可以保证共享变量的可见性和有序性。

保证可见性：

• 写屏障（sfence）保证在该屏障之前的，对共享变量的改动，都同步到主存当中

public void actor2(I_Result r) 
 num = 2;
 ready = true; // ready 是 volatile 赋值带写屏障
 // 写屏障

• 读屏障（lfence）保证在该屏障之后，对共享变量的读取，加载的是主存中最新数据

public void actor1(I_Result r) 
 // 读屏障
 // ready 是 volatile 读取值带读屏障
 if(ready) 
 r.r1 = num + num;
  else 
 r.r1 = 1;
 

---

保证有序性：

• 写屏障会确保指令重排序时，不会将写屏障之前的代码排在写屏障之后

public void actor2(I_Result r) 
 num = 2;
 ready = true; // ready 是 volatile 赋值带写屏障
 // 写屏障

• 读屏障会确保指令重排序时，不会将读屏障之后的代码排在读屏障之前

public void actor1(I_Result r) 
 // 读屏障
 // ready 是 volatile 读取值带读屏障
 if(ready) 
 r.r1 = num + num;
  else 
 r.r1 = 1;
 

volatile 不能解决指令交错（不能保证原子性）：

• 写屏障仅仅是保证之后的读能够读到最新的结果，但不能保证读跑到它前面去
• 而有序性的保证也只是保证了本线程内相关代码不被重排序

---

2.3 volatile解决可见性示例

对此，网上的解释是这样的：

按照这个说法，另外的线程去读共享变量读的应该只是副本（即false）

真正原因：JIT即时编译器

---

3. 悲观锁 vs 乐观锁

要求

• 掌握悲观锁和乐观锁的区别

对比悲观锁与乐观锁

• 悲观锁的代表是 synchronized 和 Lock 锁

  • 其核心思想是【线程只有占有了锁，才能去操作共享变量，每次只有一个线程占锁成功，获取锁失败的线程，都得停下来等待】
  • 线程从运行到阻塞、再从阻塞到唤醒，涉及线程上下文切换，如果频繁发生，影响性能
  • 实际上，线程在获取 synchronized 和 Lock 锁时，如果锁已被占用，都会做几次重试操作，减少阻塞的机会

• 乐观锁的代表是 AtomicInteger，使用 cas 来保证原子性

  • 其核心思想是【无需加锁，每次只有一个线程能成功修改共享变量，其它失败的线程不需要停止，不断重试直至成功】
  • 由于线程一直运行，不需要阻塞，因此不涉及线程上下文切换
  • 它需要多核 cpu 支持，且线程数不应超过 cpu 核数

3.1 乐观锁图示

乐观锁是一种乐观思想，假定当前环境是读多写少，遇到并发写的概率比较低，读数据时认为别的线程不会正在进行修改（所以没有上锁）。写数据时，判断当前与期望值是否相同，如果相同则进行更新（更新期间加锁，保证是原子性的）。

Java中的乐观锁：CAS（Compare And Set），比较并替换，比较当前值（主内存中的值），与预期值（当前线程中的值，主内存中值的一份拷贝）是否一样，一样则更新，否则继续进行CAS操作。

如上图所示，乐观锁可以同时进行读操作，读的时候其他线程不能进行写操作。

---

3.2 悲观锁图示

悲观锁是一种悲观思想，即认为写多读少，遇到并发写的可能性高，每次去拿数据的 时候都认为其他线程会修改，所以每次读写数据都会认为其他线程会修改，所以每次读写数据时都会上锁。其他线程想要读写这个数据时，会被这个线程block，直到这个线程释放锁然后其他线程获取到锁。

Java中的悲观锁：synchronized修饰的方法和方法块、ReentrantLock锁。

如上图所示，只能有一个线程进行读操作或者写操作，其他线程的读写操作均不能进行（被阻塞）。

---

---