【JavaEE初阶系列】——synchronized 的特性(互斥和可重入性）

目录

💻synchronized 的特性

🖥️互斥及使用示例

🚩锁修饰代码块

🚩锁修饰实例方法/静态方法

🎈锁修饰实例方法

🎈锁修饰静态方法

🚩总结 

🖥️可重入

🚩死锁的现象 

🚩死锁

🎈一个线程一把锁

🎈俩个线程俩把锁

🎈哲学家吃饭(M个线程N个锁)

🚩死锁的成因

---

从上一篇【JavaEE初阶系列】—— 一万字让你了解线程类方法属性以及线程状态和线程安全问题！-CSDN博客

我们知道线程安全的原因，怎么引起了线程安全问题。接下来我将会讲述如何解决线程安全问题。

上一篇最后讲了，导致count加起来结果不是1w的原因是 count++不是原子性，因为在count++的过程中会经历三个步骤，导致了在多线程的情况下，操作系统，线程的调度顺序是随机的（抢占式执行），所以我们需要加锁。

---

💻synchronized 的特性

---

🖥️互斥及使用示例

🚩锁修饰代码块

        synchronized在使用的时候，要搭配一个代码块{} ,进入{ 就会加锁，出了} 就会解锁。在已经加锁的状态下，另一个线程尝试同样加这个锁，就会产生“所冲突/锁竞争",后一个线程就会阻塞等待，一直等到前一个线程解锁为止。

        ()中需要表示一个用来加锁的对象，这个对象是啥不重要，重要的是通过这个对象来区分俩个线程是否在竞争同一个锁。如果俩个线程是在针对同一个对象加锁，就会有锁竞争，如果不是针对同一个对象加锁，就不会有锁竞争，仍然是并发执行。

        你可以将锁想想成一个女生A，一个男生喜欢这个女生A，然后追到手了，就相当于给女生A枷锁了，如果另一个男生B也想追这个女生A，他就必须得阻塞等待，只有等男生A和女生A分手后，他才有机会。但是如果男生B追其他的女生，就不会受到男生A和女生A的影响。

如果按照这样的编程方式，俩个线程是针对同一个对象加锁的，就会有锁竞争。但是线程t2会阻塞等待，等到t1线程结束了之后，t2线程才会开始。

public class Test {
    public static int count=0;
    public static void main(String[] args) throws InterruptedException {
        Object object=new Object();
        Thread t1=new Thread(()->{
            for (int i = 0; i <5000 ; i++) {
                synchronized (object){
                    count++;
                }
            }
        });

        Thread t2=new Thread(()->{
            for (int i = 0; i < 5000; i++) {
                synchronized (object) {
                    count++;
                }
            }
        });
        t1.start();
        t2.start();
        t1.join();
        t2.join();
        System.out.println(count);
    }
}

---

记住：

• 锁对象到底用哪个对象，是无所谓的，对象是谁，不重要，重要的是俩线程加锁的对象，是否是同一个对象。
• 这里的意义/规则，有且只有一个。当俩个线程同时尝试对一个对象加锁，此时就会出现"锁冲突/锁竞争",一旦竞争出现，一个线程能够拿到锁，继续执行代码，一个线程拿不到锁，就只能阻塞等待，等待前一个线程释放锁之后，它才会有机会拿到锁，继续执行。 （并发执行 =》串行执行》

---

🚩锁修饰实例方法/静态方法

🎈锁修饰实例方法

class Counter{
    public int count;
    synchronized public void  increase(){
        count++;
    }
    public void increase1(){
        synchronized (this){
            count++;
        }
    }
}

以上俩种写法都是可以的，只是上面的写法是下面写法的简化版。此时用的是this锁对象了。

---

🎈锁修饰静态方法

  synchronized public static void increase(){
        count++;
    }
    public void increase1(){
        synchronized (Counter.class){
            count++;
        }
    }

---

public static void main(String[] args) throws InterruptedException {
        Object object=new Object();
        Counter counter=new Counter();
        Thread t1=new Thread(()->{
            for (int i = 0; i <5000 ; i++) {
                counter.increase();
            }
        });

        Thread t2=new Thread(()->{
            for (int i = 0; i <5000 ; i++) {
                counter.increase();
            }
        });
        t1.start();
        t2.start();
        t1.join();
        t2.join();
        System.out.println(counter.count);
    }

---

🚩总结 

锁可以修饰代码块，也可以修饰实例方法和静态方法。其实根本都是对count进行加锁。

代码块中的锁对象可以是任意类型的对象，但多个线程共享的锁对象必须是同一个（因为对同一个变量进行修改）

代码块，实例方法，静态方法的锁是不同的

• 代码块的锁是自己定义的任意类型的对象。
• 实例方法就是调用该方法的当前对象，也就是this指向的对象。
• 静态方法不需要创建对象就可以直接用"类名.方法名()"方式调用。java中静态方法的锁是该方法所在类的class对象，class对象在装载该类的时候自动创建，该对象可以直接用"类名.class"的方式获取。

---

synchronized 用的锁是存在 Java 对象头里的。

• 可以粗略理解成, 每个对象在内存中存储的时候, 都存有一块内存表示当前的 "锁定" 状态(类似于厕所的 "有人/无人").
• 如果当前是 "无人" 状态, 那么就可以使用, 使用时需要设为 "有人" 状态.
• 如果当前是 "有人" 状态, 那么其他人无法使用, 只能排队.

理解阻塞等待：

针对每一把锁，操作系统内部维护了一个等待队列，当这个锁被某个线程占有的时候，其他线程尝试对其加锁的时候，就加不上了，就会阻塞等待，一直等到之前的线程解锁之后，由操作系统唤醒一个新的线程，再来获取这个锁。

注意:

上一个线程解锁之后, 下一个线程并不是立即就能获取到锁. 而是要靠操作系统来 "唤醒". 这

也就是操作系统线程调度的一部分工作.

假设有 A B C 三个线程, 线程 A 先获取到锁, 然后 B 尝试获取锁, 然后 C 再尝试获取锁, 此时 B 和 C 都在阻塞队列中排队等待. 但是当 A 释放锁之后, 虽然 B 比 C 先来的, 但是 B 不一定就能获取到锁, 而是和 C 重新竞争, 并不遵守先来后到的规则.

---

🖥️可重入

synchronized 同步块对同一条线程来说是可重入的，不会出现自己把自己锁死的问题；

定义： 一个线程，连续针对一把锁，加锁两次，不会出现死锁 ，满足这个条件，就是"可重入",不满足就是"不可重入"性。(可重入锁就是可以重复进入的锁，也叫递归锁。前提是同一把锁，如同一个类、同一个实例、同一个代码块)

理解 "把自己锁死"

• 一个线程没有释放锁, 然后又尝试再次加锁

可重入锁的意义之一在于防止死锁

---

🚩死锁的现象 

 public static void main(String[] args) {
        Object object=new Object();
        Thread t=new Thread(()->{
            synchronized (object){
                synchronized (object){
                }//(2)
            }//(1)
        });
    }

一个锁对象object，一个线程t，第一次加锁，假设能够加锁成功，此时的object就属于"被锁定"状态，再进行第二次加锁的时候，很明显，object已经是锁定的状态了，第二次加锁操作，原则上来说，是应该要"阻塞等待"的，应该是等待到，锁被释放了之后，才能加锁成功.

但是实际上，一旦第二次加锁的时候阻塞了，就会出现死锁的现象。(线程卡死了)

如果第二次想要加锁成功的话，就需要第一次的加锁释放锁，第一次加锁要想释放锁，就需要执行完完}(1)的位置。要执行到(1) 就需要让第二次加锁能够成功，代码才能成功执行。由于第二次加锁导致了代码阻塞住了，当前没有办法执行到}(1),也就无法释放锁了。

上面的代码很明显是个bug，但是在java中 将synchronized设计成"可重入锁"就可以有效的解决上述死锁的现象。（让锁记录一下，是哪个线程给它锁住的，后续再加锁的时候，如果加锁的线程就是持有锁的线程直接加锁成功了）

public class Test3 {
    public static void main(String[] args) throws InterruptedException {
        Object object=new Object();
        Thread t=new Thread(()->{
            synchronized (object){
                synchronized (object){
                    System.out.println("synchronized设计成可重入锁");
                }
            }
        });
        t.start();
        t.join();
    }
}

但是有一个问题：

上述代码中，synchronized是可重入锁，没有因为第二次加锁而死锁，但是当代码执行到}(2),此时，锁是否应该释放呢？ ——不能释放

不管加锁多少层，N层，都是在最外层才能释放锁。

这就引入了计数器，锁对象中，不光要记录谁拿了锁，还要记录，锁被加了几次

• 没加锁一次，计数器+1
• 每解锁一次，计数器就-1

出了最后一个大括号，恰好就减成0了，才真正的释放锁。

public class Test3 {
    public static int count=0;
    public static void main(String[] args) throws InterruptedException {
        Object object=new Object();
        Thread t=new Thread(()->{
            synchronized (object){
                count++;
                synchronized (object){
                    System.out.println("synchronized设计成可重入锁");
                    count++;//加锁++
                }
                count--;//解锁--
                synchronized (object){
                    count++;//加锁++
                }
                count--;//解锁--
            }
            count--;
        });
        t.start();
        t.join();
        System.out.println(count);
    }
}

通过加锁+1，解锁-1的操作，我们最后出了大括号之后，恰好就减成0了。

---

🚩死锁

🎈一个线程一把锁

• 一个线程，针对一把锁，连续加锁两次，如果是不可重入锁，就会出现死锁现象，被synchronized修饰就是可重入锁。

---

🎈俩个线程俩把锁

• 俩个线程，俩把锁。（此时无论是不是可重入锁，都会死锁）就相当于 {车钥匙锁家里了，家钥匙锁车里了}

线程t1获取锁A，t2线程获取锁B

线程t1获取锁B，t2线程获取锁A

public class Test4 {
    private static Object locker1=new Object();
    private static Object locker2=new Object();
    public static void main(String[] args) throws InterruptedException {
        Thread t1=new Thread(()->{
            synchronized (locker1){
                try {
                    Thread.sleep(1000);
                } catch (InterruptedException e) {
                    throw new RuntimeException(e);
                }
                synchronized (locker2){
                    System.out.println("t1加锁成功");
                }
            }
        });

        Thread t2=new Thread(()->{
            synchronized (locker2){
                try {
                    Thread.sleep(1000);
                } catch (InterruptedException e) {
                    throw new RuntimeException(e);
                }
                synchronized (locker1){
                    System.out.println("t2加锁成功");
                }
            }
        });
        t1.start();
        t2.start();
    }
}

此时就产生了死锁效果。如果线程1没有sleep的话，是不会出现死锁现象的。这是为什么呢？因为t1.start()的时候，并发执行，首先加locker1的锁，然后没有sleep，此时t2线程就进行了，然后t1线程加锁locker2的基本上同时加锁t2线程locker2.并没有出现t1线程获取locker2锁同时，然后t2线程获取locker1锁.因为中间没有sleep。

---

🎈哲学家吃饭(M个线程N个锁)

哲学家相当于线程，筷子相当于锁，同一时刻，五个哲学家发现，他们的右手边都没有筷子，与时只能拿起左手的筷子，此时，五个哲学家发现，他们的右手边都没有筷子，只能阻塞等待，等待过程中，，不会放下左手的筷子。这就造成了严重的死锁现象了。

---

🚩死锁的成因

死锁的成因涉及到四个必要条件。

• 1.互斥使用(锁的基本特性）：当一个线程持有一把锁之后，另一个线程想要拥有这把锁，就需要阻塞等待（适用于 串行执行 二线程一把锁）
• 2.不可抢占(锁的基本特征）：当锁已经被线程1拿到之后，线程2只能等线程1主动释放，不能强行抢占。（男生A和女生A已经在一起了，男生B不能强行让女生A和他在一起，除非等女生A真的不喜欢男生A了，才会和男生B在一起，也适用于 串行执行）
• 3.请求保持(代码结构）：一个线程尝试获取多把锁。（先拿到锁1之后，再尝试获取锁2，获取的时候，锁1不会释放 嵌套执行）
• 4.循环等待/环路等待（代码结构): 等待的依赖关系，形成环了。

解决死锁，核心就是破坏上述的必要条件，只要破坏一个，死锁就形成不了了。

• 1和2破坏不了（synchronized自带特性，你无法干预）
• 对于3来说，调整代码结构，避免编写”锁前套“逻辑
• 对于4来说，可以预定加锁的顺序，就可以避免循环等待

针对锁进行编号，比如约定，加多把锁的时候，先加编号小的锁，后加编号大的锁。（所有的线程都要遵守这个规则）此时循环等待就破除了，上述系统就不会再出现死锁了。

滑稽1先拿上编号最小的1，然后滑稽2拿上2筷子，滑稽3拿上3筷子，滑稽4拿上4筷子，此时滑稽5拿不了1筷子，只能等待，所以此时滑稽4就可以拿到5筷子，等滑稽4吃完了后，放下，4，5筷子之后，滑稽3就可以拿到4筷子了，以此类推，滑稽1吃完后，滑稽5就可以同时拿到1和5筷子了。

此时就解决了死锁的问题了。

---

synchronized使用规则上，并不复杂，抓住一个原则：两个线程针对同一个对象加锁，就会产生锁竞争。

其实锁还有个特性是：刷新内存 后面讲到volatile 即可明白。 

---

今天报考六级了。