Java编程--synchronized/死锁/可重入锁/内存可见性问题/wait()、notify()

前言

逆水行舟，不进则退！！！

线程安全

synchronized原子锁

可重入锁（递归锁）

死锁

内存可见性问题

wait()、notify()

线程安全

线程安全是指在多线程环境下，程序的行为表现仍然符合我们预期，也就是说，在单线程环境下应该的结果，在多线程环境下也能保证。如果多线程环境下代码运行的结果是不符合我们预期的，即出现数据污染等意外情况，则这个程序就是线程不安全的。

导致线程不安全的主要因素包括抢占式执行、共享变量等。当存在多个线程并行执行且可能会同时访问和修改同一块内存区域时，如果没有进行适当的同步控制，就可能出现线程安全问题。

线程安全问题的罪恶之源就是多线程之间的抢占式执行。由于线程的前瞻是执行，导致当前执行到任意一个指令的时候，线程都可能被调度走，cpu 让别的线程来执行。

synchronized原子锁

synchronized 也叫做同步机制，要解决线程安全问题，我们就需要将那些有抢占式执行安全隐患的代码原子化，也就是将代码的执行过程变的不可拆分。这样就杜绝了抢占式执行的安全隐患。

public class ThreadDemo2 {
    //静态成员属性
    static int count = 0;
    /*public static synchronized void counter() {
        count++;
    }*/

    // 静态成员方法 不加锁
    public static void counter() {
        count++;
    }
    
    
    public static void main(String[] args) throws InterruptedException {
        
        Thread t1 = new Thread(() -> {
            for(int i = 0; i < 50000; i++) {
                counter();
            }
        });

        Thread t2 = new Thread(() -> {
            for(int i = 0; i <50000; i++) {
                counter();
            }
        });

        t1.start();
        t2.start();
        t1.join();
        t2.join();
        System.out.println(count);
    }
}

上面代码中，有一个静态成员属性，还有一个静态方法对这个静态成员属性进行自增操作，然后呢，创建了两个线程，同时调用这个静态方法，每个线程调用50000次，按照这样的逻辑来说，最后count的值应该是100000，但是实际运行结果表示，100000只是在概率上可能达到。多次运行结果后，count值的范围出现在50000 到 100000之间。

要弄清楚上面代码中的线程安全问题，我们首先要清楚一个知识点：在Java中，自增操作看上去是一步执行完毕的，

实际上分为3个步骤：

1，先把内存中的值读取到 CPU 的寄存器中 load 操作

2，把 CPU 寄存器里的数值进行 +1 运算 add 操作

3，把得到的结果写回到内存中 save 操作

在抢占式执行的环境下，多线程之间的执行顺序由无数种可能。synchronized 的出现，可以让一次自增操作变得原子化，将自增的这个操作变得不能分割。给自增操作上了锁之后，当线程1在进行自增操作时，若是线程2 也要进行自增操作，那就只能阻塞等待，等待线程1的自增操作执行完毕，释放锁之后，然后线程2 才能进行自增操作。

注意：synchronized 只是将执行步骤锁住，并不是说在线程在执行上锁代码时不能被CPU调度，线程是可以被调度走的，若是没有执行完就被调度走，其他阻塞等待的线程也就只能继续等待。直到锁被释放。

如果两个线程针对同一个对象进行加锁，就会出现所竞争/ 锁冲突。一个线程能够获取到锁（先到先得），另一个线程则阻塞等待，等待到上一个线程解锁，它才能获取锁成功。

如果两个线程针对不同对象加锁，此时不会发生锁竞争/ 锁冲突，这俩线程都能获取到各自的锁，不会有阻塞等待了。

现在，在上述代码中用synchronized 修饰 counter() 方法，这样就是对counter() 方法上了锁，这时再执行代码，结果就是我们预期的 100000 次了。

public class ThreadDemo2 {
    static int count = 0;
    /*public static synchronized void counter() {
        count++;
    }*/
    public static synchronized void counter() {
        count++;
    }
    public static void main(String[] args) throws InterruptedException {
        Thread t1 = new Thread(() -> {
            for(int i = 0; i < 50000; i++) {
                counter();
            }
        });

        Thread t2 = new Thread(() -> {
            for(int i = 0; i <50000; i++) {
                counter();
            }
        });

        t1.start();
        t2.start();
        t1.join();
        t2.join();
        System.out.println(count);
    }
}

可重入锁（递归锁）

一个线程对同一个对象，连续加锁两次，是否会有问题，如果没有问题，就说明该锁是可重入锁；如果有问题，就说明是不可重入锁。

也就是，一个线程对一段代码加锁了，但是还未释放锁；紧接着获取到了锁。这连着两次加锁如果可以成功，就说明是可重入。

现在有个问题是：可重入加锁为什么能成功？一般来说，一个线程对一个对象进行加锁后，再有线程想要对这个线程进行加锁操作，就会阻塞。然而随着业务的需求，有一种特殊情况还需要考虑，就是第二次加锁的线程和第一次加锁的线程是同一个。这个时候就要考虑开个绿灯行方便。这个时候会有一个计数器来计算锁的个数，每加锁一次，计数器自增。同样的每解锁一次，计数器自减，直到计数器自减为0后，其他线程才可进入该对象。也就是说，在对象被上锁的同时，会记录下，当前的锁是被那个线程所持有。

可重入锁的应用场景：

定时任务：执行定时任务时，如果任务执行时间可能超过下次计划执行时间，可以使用可重入锁来忽略任务的重复触发，确保该任务只有一个线程在执行。

死锁

什么是死锁？

答：死锁指的是两个或两个以上的进程/线程/运算单元因为互相竞争资源而导致的一种阻塞现象。具体来说，是这些线程互相持有对方所需的资源，导致它们都无法向前推进，若无外力作用，这些进程都将无法推进下去，从而产生永久阻塞的问题。

死锁产生的四个必要条件如下：

1. 互斥条件：线程1 拿到了锁，线程2 就得等着。

2. 请求与保持条件：线程1拿到了锁A，尝试获取锁B，没得逞，然后锁A也不释放。

3. 不可剥夺条件：线程1拿到了锁之后，只能等线程1主动释放锁，别的线程抢不走。

4. 循环等待条件：线程1 拿到了锁A ，申请获取锁B，线程2拿到了锁B，申请获取锁A，线程1在等线程2 释放锁B，线程2 在等线程1 释放锁A。一直等等等。

这四个条件是死锁发生的必要条件，只要系统发生死锁，这些条件必然成立。

虽然说死锁产生的原因有四个，而且是缺一不可的，但是呢，我们若想做到预防死锁，其实就只能破坏第四个条件，因为前三个条件都是锁的基本特性，（至少是针对synchronized 这把锁来说，前三点，想动也动不了。）循环等待是这4个条件里，唯一一个和代码结构相关的，也是程序员可以控制的。

内存可见性问题

内存可见性问题是指在多线程环境下，当 A线程正在使用对象状态而 B线程同时修改该对象状态，而B线程修改的对象状态对 A线程不可见。

要理解这个问题，我们首先要知道CPU缓存的相关知识。今天的CPU主要采用三层缓存：L1、L2是本地核心内缓存，即一个核一个。如果机器是4核，那就有4个L1和4个L2。L3缓存是所有核共享的，无论你的CPU是几核，这个CPU中只有一个L3。

由于每个线程执行的时候操作的都是同一个CPU的缓存，这就可能导致某个线程修改了对象的状态，但是在其它线程的缓存中，这个对象的值还没有被更新，这就是内存可见性问题。

内存可见性问题主要是针对多核CPU架构设计的。对于单核CPU，由于同一时间只有一个线程在执行，不存在多线程竞争导致的数据不一致问题，因此单核CPU不会出现内存可见性问题。

内存可见性问题的出现，部分源自编译器/JVM在多线程环境下的优化。编译器优化的本质是对代码进行智能分析判断，以提高程序运行效率。然而，这种优化有时可能会产生误判，导致多线程环境下的数据不一致问题，也就是内存可见性问题。

举个例子：

在这种情况下，我们需要手动干预，防止编译器做出错误的优化。一个常见的解决方法就是在变量前加上volatile关键字，这可以确保修饰的变量在各个线程中的可见性。

volatile关键字。（volatile意为：易变的、易失的）意思就是告诉编译器，这个变量是会改变的，你一定要每次都重新读取这个变量的内存内容。指不定什么时候就改变了，不能随便优化。

此外，内存屏障指令也可以用来强制刷新工作内存中的值，使得所有线程都能看到最新的值。

值得注意的是，禁用缓存和编译优化虽然可以解决可见性和有序性的问题，但这样会降低程序的运行效率。因此，在实际编程中，我们需要在保证程序运行效率和数据一致性之间找到一个平衡点。

wait()、notify()

wait() 和 notify() 可以更好的控制多线程之间的执行顺序。

多线程最大的问题是，抢占式执行，随机调度。而随机调度对程序员来说，非常的不友好。所以就想了一些办法，来控制线程之间的执行顺序。虽然线程在内核里的调度是随机的，但是可以通过一些 API 让线程主动阻塞。中东放弃CPU（给别的线程让路）

举个例子：t1、t2 俩线程，希望 t1 先干活，干的差不多了，再让 t2 来干，就可以让 t2 先wait（阻塞），等着 t1 干的差不多了，通过 notify 通知 t2，把 t2 唤醒，让 t2 接着干。

有wait notify ，那为什么还要有 join 呢？

答：从功能上说，wait 和 notify 比 join 功能更强，覆盖了 join 的功能。但是呢，前者使用起来要比 join 麻烦不少。

这里这个异常：

这里的这个异常要注意一下，多线程中，很多带有阻塞功能的方法都带这个异常，这些方法都是可以被 interrupt 方法通过这个异常给唤醒。

若wait不加任何参数，那就是一个“死等”，一直等待，直到有其他线程唤醒。

wait执行的操作具体如下：

1，先释放锁；

2，进行阻塞等待；

3，收到通知后，重新尝试获取锁，并且在获取锁之后，继续往下执行。

如果在执行wait的时候，线程并没有锁，那么会报一个非法的锁状态异常；

例如：上图代码执行结果如下：

下图代码中就很好的执行了wait命令：

这里的wait是阻塞了，阻塞在synchronized代码块里，实际上是释放了锁，此时其他的线程是可以获取到Object这个对象的锁的。

notify：notify这个方法必须在获取到锁之后才能生效。也就是说在java中notify 是必须和 synchronized 来进行搭配使用，

此处的 notify 通知得和 wait 配对，

如果wait 使用的对象和notify 使用的对象不同，则此时notify 不会有效果。（notify 只能唤醒在同一个对象上等待的线程。）

还有一个问题：

这里如果直接这么写，由于线程调度的不确定性，有可能是t2线程的notify 先执行，这样的话也没有起到任何作用。

要时刻牢记，线程是抢占式执行的！！！

wait 无参数就是死等

wait 带参数，就是指定了最大等待时间。

wait看起来和sleep 有点像：虽然都是能指定等待时间，虽然也都能被提前唤醒（wait使用notify唤醒，sleep使用interrupt唤醒）。但是表示的含义截然不同。notify唤醒wait 是不会有任何异常的。（正常的业务逻辑） interrupt唤醒sleep则是出异常了（表示一个出问题了的逻辑）

如果有多个线程在等待object对象，此时有一个线程在执行 object.notify()，这时是随机唤醒一个等待的线程，（不知道具体是哪个） notifyAll是唤醒所有wait object的线程。

我是专注学习的章鱼哥~