synchronized 同步块对同⼀条线程来说是可重⼊的，不会出现⾃⼰把⾃⼰锁死的问题

如何理解把自己锁死

public void add(){synchronized(this){count++;}
}

synchronized(counter){counter.add();
}

一旦调用的层次较深就容易出现这样的情况

要想解除阻塞需要往下执行才可以

要往下执行就要等到第一次的锁被释放

这样的问题就称为“死锁”dead lock

1.第一次加锁能成功（锁没有人使用）

2.第二次进行加锁，此时意味着锁对象已经被占用的状态，第二次加锁就会触发阻塞等待

死锁是一个非常严重的bug使代码执行到这一块之后就卡住

为了解决上述的问题，java的synchronized就引入了可重入的概念

当某个线程针对一个锁加锁成功之后

后续该线程再次针对这个锁进行加锁

不会触发阻塞而是直接往下走

因为当前这把锁就是被这个线程持有

但是，如果是其他线程尝试加锁就会正常阻塞

可重入锁的实现原理，关键在于让锁对象内部保存，当前是哪个线程持有的这把锁

后续有线程针对这个锁加锁的时候，对比一下，锁的持有者的线程是否和当前加锁的线程是同一个

synchronized(counter){//真正加锁 1synchronized(counter){//放行 2synchronized(counter){//放行 3counter.add();}//3->2}//2->1
}//1->0

最外层，真正加锁

最外层，真正解锁

站在jvm的视角，看到多个}需要执行

jvm如何知道哪个}是真正解锁的那个

先引入一个变量，计数器（0）

每次触发{的时候，count++；

每次触发}的时候，count--；

当count--为0的时候就是真正需要解锁的时候

---

如何自己实现一个可重入锁？

1.在锁内部记录当前是哪个线程持有的锁，后续每次加锁，都进行判定

2.通过计数器，记录当前加锁的次数，从而确定何时真正进行解锁

---

关于死锁

一个线程，一把锁，连续加锁两次

两个线程，两把锁，每个线程获取到一把锁之后，尝试获取对方的锁

           synchronized (locker1){try {Thread.sleep(1000);} catch (InterruptedException e) {throw new RuntimeException(e);}synchronized (locker2){System.out.println("t1线程两个锁都获取到");}}

必须是，拿到第一把锁，再拿第二把锁（不能释放第一把锁）

Thread-0因为竞争锁的缘故而阻塞了

---

如果不加sleep是否还会出现一样的现象

不一定

这就看具体的顺序

加上sleep为了确保

t1拿到locker1

t2拿到locker2

等待1s

t1拿到locker2

t2拿到locker1

如果不加sleep，很可能t1一口气就把locker1和locker2都拿到了，这个时候t2还没开动

自然无法构成死锁

---

让你手写一个出现死锁的代码

c++方向直接加锁两次就行了

java方向就得通过上述代码两个线程两把锁，精确控制好加锁的顺序

---

死锁的第三种情况 N个线程M把锁

一个经典模型，哲学家就餐问题

5个哲学家随机触发吃面条和思考人生

5个哲学家就相当于5个线程

5根筷子就相当于5把锁

每个线程只需拿到其中的两根筷子即可

大部分情况下上述模型可以很好运转

一些极端情况下会造成死锁

同一时刻大家都想吃面条

同时拿起左手的筷子

此时任何一个线程都无法拿起右手的筷子

---

如何避免代码中出现死锁呢

死锁是怎样构成的

构成死锁的四个必要条件

1.锁是互斥的.（锁的基本性质）一个线程拿到锁之后，另一个线程再尝试获取锁，必须要阻塞等待

2.锁是不可抢占（不可剥夺）的.（锁的基本特性）线程1拿到锁，线程2也尝试获取这个锁，线程2必须阻塞等待，而不是线程2直接把锁抢过来

//至少，java的synchronized是遵守这两点

3.请求和保持.一个线程拿到锁1后，不释放锁2的前提下，获取锁2

如果先放下左手的筷子，再拿右手的筷子就不构成死锁

代码加锁的时候不要去“嵌套”

这种做法通用性不够的

有些情况确实需要拿到多个锁再进行某个操作

4.循环等待.多个线程多把锁之间的等待过程，构成了“循环”

a等待b，b等待a或者a等待b，b等待c，c等待a

约定好加锁的顺序就可以破除循环等待了

约定，每个线程加锁的时候

永远是先获取序号小的锁

后获取序号大的锁

//破坏掉上述的3或4任何一个条件都能够打破死锁

---

java标准库中的线程安全类

数据结构，集合类

线程不安全

ArrayList

LinkedList

HashMap

TreeMap

HashSet

TreeSet

StringBuilder

集合类自身没有进行任何加锁限制

线程安全

Vector(不推荐使用）

HashTable(不推荐使用）

ConcurrentHashMap

StringBuffer

在关键方法加了synchronized

不是写了synchronized就100%线程安全

得具体代码具体分析

加锁这个事情不是没有代价的

一旦代码中使用了锁意味着代码可能会因为锁的竞争产生阻塞=>程序执行的效率大打折扣

一定要思考清楚这个地方是否确实需要锁

不需要的时候不要乱加

还有的虽然没有加锁，但是不涉及“修改”，仍然是线程安全的

String