Java 多线程 --- 锁的概念和类型划分

马达加斯加D

已于 2023-03-09 14:53:14 修改

阅读量407

点赞数

分类专栏： # Java --- 多线程并发文章标签： java jvm 开发语言

于 2023-03-02 12:27:15 首次发布

本文链接：https://blog.csdn.net/weixin_38803409/article/details/129247187

版权

Java --- 多线程并发专栏收录该内容

12 篇文章 1 订阅

订阅专栏

Java 多线程 --- 锁的概念和类型划分

锁的概念
锁可以保证 --- 原子性, 可见性, 有序性
乐观锁与悲观锁
公平锁与非公平锁
什么是可重入锁
独占锁与共享锁
轻量级锁和重量级锁
自旋锁 (Spinlock)
锁泄露

锁的概念

锁可以将多个线程对共享数据的并发访问转换为串行访问, 这样一个共享数据一次只能被一个线程访问, 该线程访问结束后其他线程才能对其进行访问.
锁具有排他性 (Exclusive), 即一个锁一次只能被一个线程持有. 所以这种锁被称为排他锁或者互斥锁 (Mutex).

锁可以保证 — 原子性, 可见性, 有序性

原子性

锁是通过互斥保障原子性的。所谓至斥(Mutual Exclusion), 就是指一个锁一次只能被一个线程持有。因此一个线程持有一个锁的时候，其他线程无法获得该锁，而只能等待其释放该锁后再申请。这就保证了临界区代码一次只能够被一个线程执行
因此，一个线程执行临界区期间没有其他线程能够访问相应的共享数据，这使得临界区代码所执行的操作自然而然地具有不可分割的特性，即具备了原子性.

从互斥的角度来看，锁其实是将多个线程对共享数据的访问由本来的并发（未使用锁的情况下）改为串行（使用锁之后)。因此，虽然实现并发是多线程编程的目标，但是这种并发往往是并发中带有串行的局部并发

可见性

可见性的保障是通过写线程冲刷处理器缓存和读线程刷新处理器绶存这两个动作实现的.
锁的获得隐含着刷新处理器缓存. 这个动作这使得读线程在执行临界区代码前（获得锁之后) 可以将其他写线程对共享变量所做的更新同步到该线程执行处理器的高速级存中
锁的释放隐含者冲刷处理器缓存这个动作，这使得写线程对共享变量所作的更新能够被"推送" 到该线程执行处理器的高速缓存中, 从而对读线程可同步. 因此锁能够保障可见性
具体原理参见 “内存屏障”

有序性

锁能够保障有序性。写线程在临界区中所执行的一系列操作在读线程所执行的临界区看起来像是完全按照源代码顺序执行的，即读线程对这些操作的感知顺序与源代码顺序一致。这是锁对原子性和可见性的保障的结果。

设写线程在临界区中更新了b、c和nag这3个共享变量。如下代码片段所示：

b = a + 1:
c = 2:
flag = true;

由于锁对可见性的保障，写线程在临界区中对上述任何一个共享变量所做的更新都对读线程可见。并且，由于临界区内的操作具有原子性，因此写线程对上述共享变量的更新会同时对读线程可见。即在读线程看来这些变盘就像足在同一刻被更新的。因此读线程并无法（也没有必要）区分写线程实际上是以什么顺序更新上述变量的. 这意味着读线程可以认为写线程是依照源代码顺序更新上述共享变量的，即有序性得以保障。
由于锁能保障有序性, 因此对于上述例子, 可有：

如果一个读线程在临界区中读取到变量c的值为2，那么flag的值必然为true。b的值必然比a的值大 1
如果一个读线程在临界区中读取到flag 的值为true,那么c的值必然为2. b的值必然比a的值大1
.等等…

尽管锁能够保障有序性，但是这并不意味着临界区内的内存操作不能够被玉排序。临界区内的任意两个操作依然可以在临界区之内被重排序（即不会重排到临界区之外）。由于临界区内的操作具有的原子性，写线程在临界区内对各个共享数据的更新同时对读线程可见，因此这种重排序并不会对其他线程产生影响。

乐观锁与悲观锁

乐观锁和悲观锁严格的说不是一种锁，而是一种策略

悲观锁

加锁是一种悲观的策略，它总是认为每次访问共享资源的时候，总会发生冲突，所以宁愿牺牲性能（时间）来保证数据安全
悲观锁的使用场景并不少见，数据库很多地方就用到了这种锁机制，比如行锁，表锁，读锁，写锁等，都是在做操作之前先上锁，悲观锁的实现往往依靠数据库本身的锁功能实现。Java程序中的Synchronized和ReentrantLock等实现的锁也均为悲观锁。

乐观锁

乐观锁就是先不加锁. 无锁是一种乐观的策略，它假设线程访问共享资源不会发生冲突，所以不需要加锁，因此线程将不断执行，不需要停止。一旦碰到冲突，就重试当前操作直到没有冲突为止
无锁的策略之一就是使用CAS机制

CAS机制

CAS的全称是Compare-and-Swap，也就是比较并交换，它包含了三个参数：V，A，B，
V表示要读写的内存位置，A表示旧的预期值，B表示新值
具体的机制是，当执行CAS指令的时候，只有当V的值等于预期值A时，才会把V的值改为B，如果V和A不同，有可能是其他的线程修改了，这个时候，执行CAS的线程就会不断的循环重试，直到能成功更新为止

CAS算是比较高效的并发控制手段，不会阻塞其他线程。但是，这样的更新方式是存在问题的，看流程就知道了，如果C的结果一直跟预期的结果不一样的话，线程A就会一直不断的循环重试，重试次数太多的话对CPU也是一笔不小的开销。
CAS的ABA问题

CAS还有个问题就是ABA问题，比如第一次拿到内存里的值时是Ａ，然后被其他线程修改为B, 然后又修改为A, 而此时去比较内存里的值会发现没有变，但是实际上还是有改动
举个通俗点的例子，你倒了一杯水放桌子上，干了点别的事，然后同事把你水喝了又给你重新倒了一杯水，你回来看水还在，拿起来就喝，如果你不管水中间被人喝过，只关心水还在，还好；但是假若你是一个比较讲卫生的人，那你肯定就不高兴了
ABA问题的解决思路: 使用版本号。在变量前面追加上版本号，每次变量更新的时候把版本号加1，那么A→B→A就会变成1A→2B→3A了