炙热的我们-Java基础篇（4.3）

盐上海

已于 2024-05-10 14:47:20 修改

阅读量154

点赞数

分类专栏： Java基础文章标签： java 线程安全锁

于 2020-08-01 23:36:03 首次发布

本文链接：https://blog.csdn.net/weixin_45386328/article/details/107014121

版权

Java基础专栏收录该内容

11 篇文章 0 订阅

订阅专栏

Java基础篇（4.3）

- 4、Java并发编程

4、Java并发编程

→ 线程安全

死锁、死锁如何排查、线程安全和内存模型的关系

死锁：不同线程分别占用对方需要的同步资源不放弃，都在等待对方放弃自己需要的同步资源，就形成了线程的死锁。

排查：1.使用jdk自带的工具。首先进入cmd命令，进入jdk安装目录下的bin目录下，执行jps命令查看端口号，得到运行的线程的id，再执行jstack命令，查看结果。（或者使用idea Terminal终端运行命令）
2.使用jconsole，在window打开 JConsole，JConsole是一个图形化的监控工具！（在windons命令窗口，输出 JConsole）
3.使用Java Visual VM

Java内存模型：

Java内存模型简称JMM，控制线程之间的通信

当多个线程对共享属性据同时进行操作时，由于本地内存数据不会立即更新到主内存，所以会导致两个线程拿到的同一数据不一样，即线程不可见性，volatile可以解决该问题，但是volatile无法保证原子性，

指令重排是指JVM在编译Java代码的时候，或者CPU在执行JVM字节码的时候，对现有的指令顺序进行重新排序。

指令重排的目的是为了在不改变程序执行结果的前提下，优化程序的运行效率。需要注意的是，这里所说的不改变执行结果，指的是不改变单线程下的程序执行结果。

然而，指令重排是一把双刃剑，虽然优化了程序的执行效率，但是在某些情况下，会影响到多线程的执行结果。

内存屏障可以解决，内存屏障也称为内存栅栏或栅栏指令，是一种屏障指令，它使CPU或编译器对屏障指令之前和之后发出的内存操作执行一个排序约束。这通常意味着在屏障之前发布的操作被保证在屏障之后发布的操作之前执行。

内存屏障共分为四种类型：

LoadLoad屏障：

抽象场景：Load1; LoadLoad; Load2

Load1 和 Load2 代表两条读取指令。在Load2要读取的数据被访问前，保证Load1要读取的数据被读取完毕。

StoreStore屏障：

抽象场景：Store1; StoreStore; Store2

Store1 和 Store2代表两条写入指令。在Store2写入执行前，保证Store1的写入操作对其它处理器可见

LoadStore屏障：

抽象场景：Load1; LoadStore; Store2

在Store2被写入前，保证Load1要读取的数据被读取完毕。

StoreLoad屏障：

抽象场景：Store1; StoreLoad; Load2

在Load2读取操作执行前，保证Store1的写入对所有处理器可见。StoreLoad屏障的开销是四种屏障中最大的。

volatile做了什么？

在一个变量被volatile修饰后，JVM会为我们做两件事：

1.在每个volatile写操作前插入StoreStore屏障，在写操作后插入StoreLoad屏障。

2.在每个volatile读操作前插入LoadLoad屏障，在读操作后插入LoadStore屏障。

volatile特性之一：

保证变量在线程之间的可见性。可见性的保证是基于CPU的内存屏障指令，被JSR-133抽象为happens-before原则。

volatile特性之二：

阻止编译时和运行时的指令重排。编译时JVM编译器遵循内存屏障的约束，运行时依靠CPU屏障指令来阻止重排。

线程安全和内存模型：https://blog.csdn.net/mikeoperfect/article/details/79133899

→ 锁

CAS、乐观锁与悲观锁、偏向锁、轻量级锁、重量级锁、可重入锁、自旋锁、阻塞锁

CAS：Compare and Swap，即比较再交换。

jdk5增加了并发包java.util.concurrent.*，其下面的类使用CAS算法实现了区别于synchronouse同步锁的一种乐观锁。JDK 5之前Java语言是靠synchronized关键字保证同步的，这是一种独占锁，也是是悲观锁。

乐观锁：乐观锁是一种乐观思想，即认为读多写少，遇到并发写的可能性低，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，采取在写时先读出当前版本号，然后加锁操作（比较跟上一次的版本号，如果一样则更新），如果失败则要重复读-比较-写的操作。

java中的乐观锁基本都是通过CAS操作实现的，CAS是一种更新的原子操作，比较当前值跟传入值是否一样，一样则更新，否则失败。

悲观锁：悲观锁是就是悲观思想，即认为写多，遇到并发写的可能性高，每次去拿数据的时候都认为别人会修改，所以每次在读写数据的时候都会上锁，这样别人想读写这个数据就会block直到拿到锁。java中的悲观锁就是Synchronized，AQS框架下的锁则是先尝试cas乐观锁去获取锁，获取不到，才会转换为悲观锁，如RetreenLock。

偏向锁：Java偏向锁(Biased Locking)是Java6引入的一项多线程优化。偏向锁，顾名思义，它会偏向于第一个访问锁的线程，如果一段同步代码一直被一个线程访问，那么该线程会自动获取锁，降低获取锁的代价，即给线程加一个偏向锁。如果在运行过程中，遇到了其他线程抢占锁，偏向锁会升级到轻量级锁。

轻量级锁： 轻量级锁是指当锁是偏向锁的时候，被另一个线程所访问，偏向锁就会升级为轻量级锁，其他线程会通过自旋的形式尝试获取锁，不会阻塞，提高性能。

重量级锁： 重量级锁是指当锁为轻量级锁的时候，另一个线程虽然是自旋，但自旋不会一直持续下去，当自旋一定次数的时候，还没有获取到锁，就会进入阻塞，该锁膨胀为重量级锁。重量级锁会让他申请的线程进入阻塞，性能降低。

可重入锁： 可重入锁又名递归锁，是指在同一个线程在外层方法获取锁的时候，再进入该线程的内层方法会自动获取锁（前提锁对象得是同一个对象或者class），不会因为之前已经获取过还没释放而阻塞。Java中ReentrantLock和synchronized都是可重入锁，可重入锁的一个优点是可一定程度避免死锁。

自旋锁： 在Java中，自旋锁是指尝试获取锁的线程不会立即阻塞，而是采用循环的方式去尝试获取锁，这样的好处是减少线程上下文切换的消耗，缺点是循环会消耗CPU。

阻塞锁： 多个线程同时调用同一个方法的时候，所有线程都被排队处理了。让线程进入阻塞状态进行等待，当获得相应的信号（唤醒，时间）时，才可以进入线程的准备就绪状态，准备就绪状态的所有线程，通过竞争，进入运行状态。

锁分类
【参考链接】https://www.cnblogs.com/hustzzl/p/9343797.html
https://www.cnblogs.com/kubidemanong/p/10777928.html

数据库相关锁机制、锁优化、锁消除、锁粗化

数据库相关锁机制：数据库锁是事务对某个数据库中的资源（如表和记录）存取前，先向系统提出请求，封锁该资源，事务获得锁后，即取得对数据的控制权，在事务释放它的锁之前，其他事务不能更新此数据。当事务撤消后，释放被锁定的资源。
数据库锁机制

共享锁：又叫S锁或者读锁，加了共享锁的数据对象可以被其他事务读取，但不能修改，通常是该数据对象被读取完毕，锁立即被释放。

排他锁：又叫X锁或者写锁，当数据对象被加上排它锁时，一个事务必须得到锁才能对该数据对象进行访问，一直到事务结束锁才被释放。在此之间其他的事务不能对它读取和修改。

行锁：行锁，字面意思理解，就是给某一行加上锁，也就是一条记录加上锁。比如之前演示的共享锁语句。
SELECT * from city where id = “1” lock in share mode; 由于对于city表中,id字段为主键，就也相当于索引。执行加锁时，会将id这个索引为1的记录加上锁，那么这个锁就是行锁。

锁优化：

1、减少锁持有时间

例如：对一个方法加锁，不如对方法中需要同步的几行代码加锁；

2、减小锁粒度

例如：ConcurrentHashMap采取对segment加锁而不是整个map加锁，后来又对node加锁，提高并发性；

3、锁分离

根据同步操作的性质，把锁划分为的读锁和写锁，读锁之间不互斥，提高了并发性。

4、锁粗化

这看起来与思路1有冲突，其实不然。思路1是针对一个线程中只有个别地方需要同步，所以把锁加在同步的语句上而不是更大的范围，减少线程持有锁的时间；

而锁粗化是指：在一个间隔性地需要执行同步语句的线程中，如果在不连续的同步块间频繁加锁解锁是很耗性能的，因此把加锁范围扩大，把这些不连续的同步语句进行一次性加锁解锁。虽然线程持有锁的时间增加了，但是总体来说是优化了的。

5、锁消除

锁消除是编译器做的事：根据代码逃逸技术，如果判断到一段代码中，堆上的数据不会逃逸出当前线程（即不会影响线程空间外的数据），那么可以认为这段代码是线程安全的，不必要加锁。

锁消除： 锁消除是发生在编译器级别的一种锁优化方式。有时候我们写的代码完全不需要加锁，却执行了加锁操作。比如，StringBuffer类的append操作：

@Override
public synchronized StringBuffer append(String str) {
    toStringCache = null;
    super.append(str);
    return this;
}

从源码中可以看出，append方法用了synchronized关键词，它是线程安全的。但我们可能仅在线程内部把StringBuffer当作局部变量使用：因此 sb 是不可能共享的资源，JVM 会自动消除 StringBuffer 对象内部的锁。

锁粗化： 通常情况下，为了保证多线程间的有效并发，会要求每个线程持有锁的时间尽可能短，但是大某些情况下，一个程序对同一个锁不间断、高频地请求、同步与释放，会消耗掉一定的系统资源，因为锁的讲求、同步与释放本身会带来性能损耗，这样高频的锁请求就反而不利于系统性能的优化了，虽然单次同步操作的时间可能很短。锁粗化就是告诉我们任何事情都有个度，有些情况下我们反而希望把很多次锁的请求合并成一个请求，以降低短时间内大量锁请求、同步、释放带来的性能损耗。

【参考链接】https://www.cnblogs.com/xdecode/p/9137804.html
https://blog.csdn.net/hefenglian/article/details/82421770

分布式锁、monitor

分布式锁： 为了防止分布式系统中的多个进程之间相互干扰，我们需要一种分布式协调技术来对这些进程进行调度。而这个分布式协调技术的核心就是来实现这个分布式锁。

分布式锁具备的条件：

在分布式系统环境下，一个方法在同一时间只能被一个机器的一个线程执行
高可用的获取锁与释放锁
高性能的获取锁与释放锁
具备可重入特性（可理解为重新进入，由多于一个任务并发使用，而不必担心数据错误）
具备锁失效机制，防止死锁
具备非阻塞锁特性，即没有获取到锁将直接返回获取锁失败

分布式锁的实现有哪些：

Memcached：利用 Memcached 的 add 命令。此命令是原子性操作，只有在 key 不存在的情况下，才能 add 成功，也就意味着线程得到了锁。
Redis：和 Memcached 的方式类似，利用 Redis 的 setnx 命令。此命令同样是原子性操作，只有在 key 不存在的情况下，才能 set 成功。
Zookeeper：利用 Zookeeper 的顺序临时节点，来实现分布式锁和等待队列。Zookeeper 设计的初衷，就是为了实现分布式锁服务的。
Chubby：Google 公司实现的粗粒度分布式锁服务，底层利用了 Paxos 一致性算法。

monitor：在JVM的规范中，有这么一些话：

“在JVM中，每个对象和类在逻辑上都是和一个监视器相关联的”
“为了实现监视器的排他性监视能力，JVM为每一个对象和类都关联一个锁”
“锁住了一个对象，就是获得对象相关联的监视器”
从这些话，看出监视器和对象锁好像是一回事，那为何要定义两个东西，若不一样，他们的关系如何？

lock与monitor的区别

1.lock的底层本身是Monitor来实现的，所以Monitor可以实现lock的所有功能

2.Monitor有TryEnter的功能，可以防止出现死锁的问题，lock没有。

3.Monitor.Enter(object)方法是获取锁，Monitor.Exit(object)方法是释放锁，这就是Monitor最常用的两个方法，当然在使用过程中为了避免获取锁之后因为异常，致锁无法释放，所以需要在try{} catch(){}之后的finally{}结构体中释放锁(Monitor.Exit())。

5.Lock关键字实际上是一个语法糖，它将Monitor对象进行封装，给object加上一个互斥锁，A进程进入此代码段时，会给object对象加上互斥锁，此时其他B进程进入此代码段时检查object对象是否有锁？如果有锁则继续等待A进程运行完该代码段并且解锁object对象之后，B进程才能够获取object对象为其加上锁，访问代码段。

【参考链接】分布式锁：https://www.jianshu.com/p/a1ebab8ce78a
monitor：https://www.cnblogs.com/wangyonglai/p/8241724.html

→ 死锁

什么是死锁、死锁如何解决

“死锁是指两个或两个以上的线程在执行过程中，由于竞争资源或者由于彼此通信而造成的一种阻塞的现象，若无外力作用，它们都将无法推进下去。此时称系统处于死锁状态或系统产生了死锁，这些永远在互相等待的进程称为死锁进程。”

当然死锁的产生是必须要满足一些特定条件的：
1.互斥条件：进程对于所分配到的资源具有排它性，即一个资源只能被一个进程占用，直到被该进程释放
2.请求和保持条件：一个进程因请求被占用资源而发生阻塞时，对已获得的资源保持不放。
3.不剥夺条件：任何一个资源在没被该进程释放之前，任何其他进程都无法对他剥夺占用
4.循环等待条件：当发生死锁时，所等待的进程必定会形成一个环路（类似于死循环），造成永久阻塞。

死锁的解除办法：

1、抢占资源。从一个或多个进程中抢占足够数量的资源，分配给死锁进程，以解除死锁状态。

2、终止（撤销）进程：将一个或多个思索进程终止（撤销），直至打破循环环路，使系统从死锁状态解脱。