文章目录
锁策略
乐观锁 VS 悲观锁
- 乐观锁：乐观锁假设认为数据一般情况下不会产生并发冲突，所以在数据进行提交更新的时候，才会正式对数据是否产生并发冲突进行检测，如果发现并发冲突了，则让返回用户错误的信息，让用户决定如何去做。
- 悲观锁：总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞直到它拿到锁。
悲观锁的问题：总是需要竞争锁，进而导致发生线程切换，挂起其他线程；所以性能不高。
乐观锁的问题：并不总是能处理所有问题，所以会引入一定的系统复杂度。
读写锁
- 把加锁操作分成了俩种 一是读锁二是写锁 也就是说在读和读之间是没有互斥的 但是在读写和写写之间就会存在互斥
- 如果一个场景是一写多度 那么使用这个效率就会很高
重量级锁 VS 轻量级锁
- 首先我们要知道加锁有一个很重要的特性就是保证原子性 原子性的功能其实来源于硬件(硬件提供了相关的原子操作的指令, 操作系统把这些指令统一封装成一个原子操作的接口, 应用程序才能使用这样的操作)
- 所以在加锁过程中 如果整个加锁逻辑都是依赖于操作系统内核 那此时就是重量级锁(代码在内核中的开销会很大) 如果大多数操作都是用户自己完成的 少数由操作系统内核完成 这种就是轻量级锁
挂起等待锁 VS 自旋锁
- 挂起等待锁表示当前获取锁失败后, 对应的线程就要在内核中挂起等待 (放弃CPU进入等待队列) 需要在锁对象释放之后由操作系统唤醒 (通常都是重量级锁)
- 自旋锁表示当前获取锁失败后 不是立刻放弃CPU 而是快速频繁的再次访问锁的持有状态, 一旦锁对象被释放就能立刻获取到锁(通常都是轻量级锁)
自旋锁的效率更高, 但是会浪费一些CPU资源 (自旋相当于CPU在那空转)
公平锁 VS 非公平锁
- 这种情况就是如果已经有多个线程在等待一把锁的释放 当释放之后, 恰好又来了一个新的线程也要获取锁
- 公平锁: 保证之前先来的线程优先获取锁
- 非公平锁: 新来的线程直接获取到锁, 之前的线程还得接着等待
实现公平锁就需要付出一些额外的代价 所以公平锁的效率是略低于非公平锁的
可重入锁
- 一个线程针对同一把锁连续加锁俩次, 不会死锁, 这种就是可重入锁
可重入锁这就像是大门的三保险锁一样 我锁一层再锁一层 这种并不会造成我们死锁住自己 因为当我们想出去的时候又可以一层一层的开锁
死锁
- 死锁是这样一种情形：多个线程同时被阻塞，它们中的一个或者全部都在等待某个资源被释放。由于线程被无限期地阻塞，因此程序不可能正常终止。
- 我们常说的死锁有三个经典场景
- 一个线程一把锁 连续加锁俩次才 (保证使用的不是可重入锁)
- 俩个线程, 俩把锁, 相互获取对方的锁
- n个线程, n把锁, 哲学家就餐问题
- 死锁产生的四个必要条件：(较为理论简单了解)
1、互斥使用，即当资源被一个线程使用(占有)时，别的线程不能使用
2、不可抢占，资源请求者不能强制从资源占有者手中夺取资源，资源只能由资源占有者主动释放。
3、请求和保持，即当资源请求者在请求其他的资源的同时保持对原有资源的占有。
4、循环等待，即存在一个等待队列：P1占有P2的资源，P2占有P3的资源，P3占有P1的资源。这样就形成了一个等待环路。
CAS
- CAS的全称是 compare and swap(字面意思就是比较交换) 他是基于硬件提供的一种基础指令, 也是基于这样的指令, 就可以实现一些特殊的功能(实现锁)
- 针对不同的操作系统，JVM 用到了不同的 CAS 实现原理
- 简而言之，是因为硬件予以了支持，软件层面才能做到。
我们假设内存中的原数据val，旧的预期值new，需要修改的新值tmp。
- 比较 new 与 val 是否相等。（比较）
- 如果比较相等，将 tmp 写入 val。（交换）
- 返回操作是否成功。
- 可见当多个线程同时对某个资源进行CAS操作，只能有一个线程操作成功，但是并不会阻塞其他线程,其他线程只会收到操作失败的信号。可见 CAS 其实是一个乐观锁。
CAS的使用
上图所示就是使用的CAS封装了一些原子类如下面代码示例第一个使用CSA的锁第二个不使用 显然结果第一个是线程安全的第二个线程是不安全的
import java.util.concurrent.atomic.AtomicInteger;
/**
* Created with IntelliJ IDEA.
* Description: If you don't work hard, you will a loser.
* User: Listen-Y.
* Date: 2020-08-04
* Time: 20:40
*/
public class Demo2 {
public static void main(String[] args) throws InterruptedException {
AtomicInteger atomicInteger = new AtomicInteger();
Thread thread = new Thread() {
@Override
public void run() {
for (int i = 0; i < 5000; i++) {
atomicInteger.addAndGet(1);
}
}
};
Thread thread1 = new Thread() {
@Override
public void run() {
for (int i = 0; i < 5000; i++) {
atomicInteger.addAndGet(1);
}
}
};
thread.start();
thread1.start();
thread.join();
thread1.join();
System.out.println(atomicInteger.get());
}
}
/**
* Created with IntelliJ IDEA.
* Description: If you don't work hard, you will a loser.
* User: Listen-Y.
* Date: 2020-08-04
* Time: 20:53
*/
public class Demo3 {
private static int count = 0;
public static void main(String[] args) throws InterruptedException {
Thread thread = new Thread() {
@Override
public void run() {
for (int i = 0; i < 5000; i++) {
count++;
}
}
};
Thread thread1 = new Thread() {
@Override
public void run() {
for (int i = 0; i < 5000; i++) {
count++;
}
}
};
thread.start();
thread1.start();
thread.join();
thread1.join();
System.out.println(count);
}
}
CAS的缺陷 ABA问题
- 这个问题就是加入现在有个num为0 有一个线程把他修改为1, 然后紧接着又有一个线程把他修改为0了 那此时仅仅通过CAS的比较是无法区分的
- 解决这个问题就需要引入额外的信息 (给变量加一个版本号 每次进行修改 都递增版本号)
synchronize的原理
- synchronize是java中的关键字，可以用来修饰实例方法、静态方法、还有代码块；主要有三种作用：可以确保原子性、可见性、有序性，原子性就是能够保证同一时刻有且只有一个线程在操作共享数据，其他线程必须等该线程处理完数据后才能进行；可见性就是当一个线程在修改共享数据时，其他线程能够看到，保证可见性，volatile关键字也有这个功能；有序性就是，被synchronize锁住后的线程相当于单线程，在单线程环境jvm的重排序是不会改变程序运行结果的，可以防止重排序对多线程的影响。
以synchronize为例学习锁优化
编辑器和JVM配合进行的
锁消除
- 锁消除本质是以编辑器和JVM代码运行的情况智能的判断当前的锁有没有必要加 如果没有必要, 就会直接把锁干掉
/**
* Created with IntelliJ IDEA.
* Description: If you don't work hard, you will a loser.
* User: Listen-Y.
* Date: 2020-08-04
* Time: 21:21
*/
public class Demo4 {
public static void main(String[] args) {
StringBuffer buffer = new StringBuffer();
buffer.append("listen");
buffer.append("listen");
buffer.append("listen");
buffer.append("listen");
System.out.println(buffer);
}
}
- 到库中我们可以发现StringBuffer是加锁线程安全的 但是在我们上面写的代码中完全不用考虑线程安全问题 所以在实际运行的时候就把锁消除了
偏向锁
- 第一个尝试加锁的线程 不会真正的加锁 而是进入偏向锁(一种很轻量的锁) 知道其他线程也来竞争这把锁的时候 才会取消偏向锁的状态 真正的进行加锁
- 这个很像我去球馆打球的时候借用人家球馆里的球的时候 当人多有人和我竞争的时候我就得去花钱租 人少的时候我就可以登记一下直接玩
- 总而言之上述这俩个优化机制就是能不加锁就不加锁
自旋锁
- 当有很多线程竞争锁的时候, 偏向锁状态被消除 此时没有得到锁的线程并不会直接直接挂起放弃 而是使用自旋锁 的方式来尝试去再次获取锁
- 自旋锁能保证让其他想竞争锁的线程尽快得到锁 但是也相应付出了一定的cpu资源
- 还是上面我去球馆打球的例子 如果此时就一个人来和我竞争这个篮球 我不会立马放弃 而是会稍微等会 看我是不是快回家了
锁膨胀
- 当锁竞争更加激烈的时候 此时就会从自旋状态膨胀成重量级锁(挂起等待锁)
- 还是我去球馆打球 竞争太激烈的时候 等待的人就会回家了 不玩了
锁粗化
- 如果一段路基中 需要多次加锁 解锁 并且在解锁的时候没有其他线程来竞争 此时就会把多组的锁操作合并在一起 (合并后的锁的粒度很比较粗 所以叫锁粗化)
- 还是我去打球的例子 比如我正在玩突然想去卫生间 然后此时还没有人和我竞争这个篮球 我就没必要把他放回去 上完卫生间再去拿回来 我直接抱着篮球上卫生间多省事