1. 死锁
1.1 定义
死锁是指两个或两个以上的进程在执行过程中，由于竞争资源或者由于彼此通信而造成的一种阻塞的现象，若无外力作用，它们都将无法推进下去。此时称系统处于死锁状态或系统产生了死锁。
1.2 产生死锁的必要条件
- 互斥条件：指进程对所分配到的资源进行排它性使用，即在一段时间内某资源只由一个进程占用。如果此时还有其它进程请求资源，则请求者只能等待，直至占有资源的进程用毕释放。
- 请求和保持条件：指进程已经保持至少一个资源，但又提出了新的资源请求，而该资源已被其它进程占有，此时请求进程阻塞，但又对自己已获得的其它资源保持不放。
- 不剥夺条件：指进程已获得的资源，在未使用完之前，不能被剥夺，只能在使用完时由自己释放。
- 环路等待条件：指在发生死锁时，必然存在一个进程——资源的环形链，即进程集合{P0，P1，P2，···，Pn}中的P0正在等待一个P1占用的资源；P1正在等待P2占用的资源，……，Pn正在等待已被P0占用的资源。
1.3 如何解决死锁
知道死锁发生的原因，解决死锁的方法也有四种：
打破互斥条件：改造独占性资源为虚拟资源，大部分资源已无法改造。
打破不可抢占条件：当一进程占有一独占性资源后又申请一独占性资源而无法满足，则退出原占有的资源。
打破占有且申请条件：采用资源预先分配策略，即进程运行前申请全部资源，满足则运行，不然就等待，这样就不会占有且申请。
-
打破循环等待条件：实现资源有序分配策略，对所有设备实现分类编号，所有进程只能采用按序号递增的形式申请资源。
避免死锁常见的算法有有序资源分配法、银行家算法。
// 产生死锁案例
// 线程1
synchronized(lock1) {
// do someThing
synchronized(lock2) {
// do someThing
}
}
// 线程2
synchronized(lock2) {
// do someThing
synchronized(lock1) {
// do someThing
}
}
具体手段：(1) 内部确认拿锁顺序，修改拿锁和释放锁顺序；(2) 采用尝试拿锁的机制
// 使用手段1解决死锁
synchronized(lock1) {
// do someThing
synchronized(lock2) {
// do someThing
}
}
// 线程2
synchronized(lock1) {
// do someThing
synchronized(lock2) {
// do someThing
}
}
// 使用tryLock尝试拿锁的机制
public class TryLock {
private static Lock No13 = new ReentrantLock();//第一个锁
private static Lock No14 = new ReentrantLock();//第二个锁
//先尝试拿No13 锁，再尝试拿No14锁，No14锁没拿到，连同No13 锁一起释放掉
private static void fisrtToSecond() throws InterruptedException {
String threadName = Thread.currentThread().getName();
Random r = new Random();
while (true) {
if (No13.tryLock()) {
System.out.println(threadName + " get 13");
try {
if (No14.tryLock()) {
try {
System.out.println(threadName + " get 14");
System.out.println("fisrtToSecond do work------------");
break;
} finally {
No14.unlock();
}
}
} finally {
No13.unlock();
}
}
//Thread.sleep(r.nextInt(3));
}
}
//先尝试拿No14锁，再尝试拿No13锁，No13锁没拿到，连同No14锁一起释放掉
private static void SecondToFisrt() throws InterruptedException {
String threadName = Thread.currentThread().getName();
Random r = new Random();
while (true) {
if (No14.tryLock()) {
System.out.println(threadName + " get 14");
try {
if (No13.tryLock()) {
try {
System.out.println(threadName + " get 13");
System.out.println("SecondToFisrt do work------------");
break;
} finally {
No13.unlock();
}
}
} finally {
No14.unlock();
}
}
// 休眠是为了方式两个线程一直同时去抢锁，导致活锁现象
//Thread.sleep(r.nextInt(3));
}
}
private static class TestThread extends Thread {
private String name;
public TestThread(String name) {
this.name = name;
}
public void run() {
Thread.currentThread().setName(name);
try {
SecondToFisrt();
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
public static void main(String[] args) {
Thread.currentThread().setName("TestDeadLock");
TestThread testThread = new TestThread("SubTestThread");
testThread.start();
try {
fisrtToSecond();
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
1.4 死锁的危害
- 线程不工作了，但是整个程序还是活着的
- 没有任何的异常信息可以供我们检查。
- 一旦程序发生了发生了死锁，是没有任何的办法恢复的，只能重启程序。
- 自身程序死锁了，还可能导致其他程序拿不到资源，导致其他程序crash。
2.活锁
两个线程在尝试拿锁的机制中，发生多个线程之间互相谦让，不断发生同一个线程总是拿到同一把锁，在尝试拿另一把锁时因为拿不到，而将本来已经持有的锁释放的过程。
线程A B 锁1,2
拿锁顺序
A(1)<2>--(1)<2>--(1)<2>--(1)<2>--(1)<2>--(1)<2>
B(2)<1>--(2)<1>--(2)<1>--(2)<1>--(2)<1>--(2)<1>
以上现象会拉长拿锁周期，因为A拿到锁1，尝试拿锁2，但是拿不到锁2。B线程先拿到锁2，尝试拿锁1。就会导致活锁现象，线程也没有死，但是不能执行期望的代码。
解决办法：每个线程休眠随机数，错开拿锁的时间。
3.线程饥饿
低优先级的线程，总是拿不到执行时间片。
4.前面《多线程并发总结录》中已经总结过Synchronized和ThreadLocal实现多线程安全。下面来总结一下CAS。在阐述CAS之前，需要先谈谈原子操作相关知识点。下面我们就开始吧。
下面从what，how，why三个方面来引出CAS。
4. 1什么是原子操作？
有两个任务A,B，每个任务需要很多步骤执行；但是对于每个线程来说，要么任务执行并且执行完成，要么不执行。这样的操作就叫原子操作。
4.2 如何实现原子操作？
实现原子操作可以使用锁，锁机制就可以满足基本需求了，但是有的时候我们的需求并非这么简单，我们需要更有效，更加灵活的机制，synchronized关键字是基于阻塞的锁机制，也就是说当一个线程拥有锁的时候，访问同一资源的其它线程需要等待，直到该线程释放锁。
使用synchronized来实现会有以下几个问题：
- 被阻塞的线程优先级很高很重要，可能会导致低优先级线程饥饿。
- 持锁线程一直不释放锁，可能会导致其他线程拿不到锁，一直无法执行(之前项目联调阶段遇到语音助理一直拿着音频焦点不释放，导致其他应用请求焦点一直拿不到焦点)
- 存在死锁的可能性
- 上下文切换比较耗时，对于简单的原子操作有些不划算
基于以上使用synchronized来实现原子操作的缺点，CAS就应运而生了。
4.3 CAS是什么？
CAS(Compare and Swap) ，通俗地讲：如果某个地址上的值和期望的值相等，则给其赋予新值，否则不做任何事儿。
每一个CAS操作过程都包含三个运算符：一个内存地址V，一个期望的值A和一个新值B，操作的时候如果这个地址上存放的值等于这个期望的值A，则将地址上的值赋为新值B，否则不做任何操作。
public class AtomicIntegerTest {
private static AtomicInteger ai = new AtomicInteger(100);
public static void main(String[] args) {
System.out.println(ai.getAndIncrement()); //100 相当于i++;
System.out.println(ai.incrementAndGet()); //102 相当于++i;
System.out.println(ai.addAndGet(20)); // 122 相当于 i+=20;
}
}
4.4 CAS实现原子操作的三大问题
4.4.1 ABA问题
因为CAS需要在操作值的时候，检查值有没有发生变化，如果没有发生变化则更新，但是如果一个值原来是A，变成了B，又变成了A，那么使用CAS进行检查时会发现它的值没有发生变化，但是实际上却变化了。
解决方案：在变量前面追加上版本号，每次变量更新的时候把版本号加1，那么A→B→A就会变成1A→2B→3A。
// 使用AtomicStampedReference或者AtomicMarkableReference来解决ABA问题，给每次修改打标签。
public class UseAtomicStampedReference {
static AtomicStampedReference asr
= new AtomicStampedReference("Jack", 0);
public static void main(String[] args) throws InterruptedException {
//拿到当前的版本号(旧)
final int oldStamp = asr.getStamp();
final String oldReference = asr.getReference();
System.out.println(oldReference + "current stamp -->" + oldStamp);
Thread rightStampThread = new Thread(new Runnable() {
@Override
public void run() {
System.out.println(Thread.currentThread().getName() + ":当前变量值："
+ oldReference + "-当前版本戳：" + oldStamp + "-"
+ asr.compareAndSet(oldReference,
oldReference + "+Java", oldStamp,
oldStamp + 1));
}
});
Thread errorStampThread = new Thread(new Runnable() {
@Override
public void run() {
String reference = asr.getReference();
System.out.println(Thread.currentThread().getName()
+ ":当前变量值："
+ reference + "-当前版本戳：" + asr.getStamp() + "-"
+ asr.compareAndSet(reference,
reference + " + Java", oldStamp,
oldStamp + 1));
}
});
rightStampThread.start();
rightStampThread.join();
errorStampThread.start();
errorStampThread.join();
System.out.println(asr.getReference() + "current stamp -->" + asr.getStamp());
}
}
AtomicStampedReference和AtomicMarkableReference区别
相同点都是为了解决CAS原子操作中给每次修改做标记。
不同点是AtomicStampedReference有版本管理的概念，每次操作之后，给stamp值加1；而AtomicMarkableReference只是在每次修改之后，把mark标志位置位。
4.4.2 循环时间长开销大
自旋CAS如果长时间不成功，会给CPU带来非常大的执行开销。
4.4.3只能保证一个共享变量的原子操作。
当对一个共享变量执行操作时，我们可以使用循环CAS的方式来保证原子操作，但是对多个共享变量操作时，循环CAS就无法保证操作的原子性，这个时候就可以用锁。
还有一个取巧的办法，就是把多个共享变量合并成一个共享变量来操作。比如，有两个共享变量i＝2，j=a，合并一下ij=2a，然后用CAS来操作ij。从Java 1.5开始，JDK提供了AtomicReference类来保证引用对象之间的原子性，就可以把多个变量放在一个对象里来进行CAS操作。
// 使用AtomicReference来解决CAS原子操作中对多个变量的修改，但是修改的变量太多，还是建议用锁的机制
public class UseAtomicReference {
static AtomicReference atomicUserRef;
public static void main(String[] args) {
UserInfo user = new UserInfo("DY", 10);//要修改的实体的实例
atomicUserRef = new AtomicReference(user);
UserInfo updateUser = new UserInfo("Jack",18);
atomicUserRef.compareAndSet(user,updateUser);
System.out.println(atomicUserRef.get());
System.out.println(user);
}
//定义一个实体类
static class UserInfo {
private volatile String name;
private int age;
public UserInfo(String name, int age) {
this.name = name;
this.age = age;
}
public String getName() {
return name;
}
public int getAge() {
return age;
}
}
}
4.5 悲观锁和乐观锁
synchronized属于悲观锁：
- 始终感觉有“贼”想谋害朕，一拿到时间片就想办法去抢“锁”
CAS属于乐观锁：
- 每次尝试去修改，一次不行下次再来，知道修改成功为止。