【JavaEE初阶】多线程(3)

欢迎关注个人主页：逸狼

创造不易，可以点点赞吗~

如有错误，欢迎指出~

目录

线程状态

线程安全

代码示例

解释

总结原因

解决方案-->加锁

t1和t2都加锁且同一个锁对象

t1和t2中只有一个加锁了

t1和t2都加锁,但锁对象不同

加锁与线程等待(join) 的区别

使用类对象加锁

加锁场景

死锁

场景1

场景2

编辑场景3

构成死锁的4个必要条件(缺一不可)

解决方案举例

方案1 避免锁嵌套

方案2 约定加锁顺序

方案3 银行家算法

线程状态

进程状态分为两种:

就绪:正在cpu上执行,或者随时可以去cpu上执行
阻塞:暂时不能参与cpu执行

Java的线程状态有 6 种

NEW 当前Thread对象虽然有了,但是内核的线程还没有(还没调用start)
TERMINATED 当前Thread对象虽然还在,但是内核线程已经销毁(线程已经结束)
RUNNABLE 就绪状态,正在cpu上运行 + 随时可以去cup上运行
BLOCKED 因为锁竞争引起的阻塞
TIMED_WAITING 有超时的等待如sleep,或者join带参数版本
WAITING 没有超时时间的阻塞等待如 join/wait

学习线程状态主要为了调试,比如遇到某个代码功能没有执行,就可以观察对应线程的状态,看是否是因为一些原因阻塞了.

线程安全

多个线程同时执行某个代码时,可能会引起一些奇怪的bug,理解线程安全才能避免/解决上述bug

代码示例

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

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

        t1.start();
        t2.start();

        t1.join();
        t2.join();

        System.out.println("count="+ count);
    }
}

因为多线程并发执行引发的bug称为"线程安全问题" 或"线程不安全"

解释

上述代码count++;在cpu视角是3个指令:

load 把内存中的数据读到cpu寄存器里
add 把cpu寄存器里的数据+1
sava 把寄存器的值,写回内存

指令是cpu执行的基本单位,如果要调度,cup至少会把当前指令执行完,

cpu调度执行线程的方式是抢占式执行,随机调度,

但是由于count++ 是三个指令,可能会出现cpu执行了其中1个指令或2个指令或3个指令就被调度走的情况(都有可能,无法预测), 所以两个线程同时对count进行++ 就容易出现bug

由于循环5w次过程中不知道有多少次的执行顺序是前两种正确情况,有多少次是其他错误情况,最终的结果就是一个不确定的值,而这个值一定小于10w

但结果也有可能小于5w

总结原因

线程在操作系统中,随机调度,抢占式执行(根本原因), 此原因无法干预(操作系统内核,作为应用层的程序员无法干预)
多个线程,同时修改一个变量(如果是一个线程修改,就没事)
修改操作,不是"原子"的,(对cpu来说,一条指令才是"原子"的,是不可分割的最小的单位)

解决方案-->加锁

解决线程安全问题,最主要的方法就是 把"非原子" 的修改,变成"原子"(通过加锁,把非原子的修改操作打包成一个整体,变成原子操作)

t1和t2都加锁且同一个锁对象

此处的加锁,没有干预到线程的调度,只是通过加锁,使一个线程在执行count++时,其他线程的count++不能插队进来

Java提供synchronized关键字来完成加锁操作,synchronizede()的'()'中需要指定一个 "锁对象" (可以指定任何对象)来进行后面的判定

t1和t2都是针对locker对象加锁,t1加锁成功后,继续执行{}里的代码,t2后加锁,发现locker对象已经被别人先锁了,t2只能排队等待(这两者的++ 操作不会并发执行了,本质上是把随机并发的执行过程强制变成了串行,从而解决了刚才的线程安全问题)

t1和t2中只有一个加锁了

t1和t2都加锁,但锁对象不同

锁对象的作用就是用来区分两个线程或多个线程是否针对"同一个对象"加锁

若是,此时就会出现阻塞(锁竞争/锁冲突)
若不是,此时不会出现"阻塞",两个线程仍然是随机调度的并发执行.

锁对象,只要是Object(或者其子类)都行,不能是int,double这样的内置类型

加锁与线程等待(join) 的区别

上述加锁后的代码本质上要比join的串行执行的效率还要高

加锁只是把线程中一小部分逻辑变成了串行执行,剩下其他部分仍然可以并发执行
join是线程 整体都串行执行

使用类对象加锁

一个Java进程中,一个类的类对象是只有唯一一个的,类对象,也是对象,也可以成为锁对象,写类对象和写其他对象没有本质区别,换句话说,写成类对象,就是'偷懒'的做法(不想单独创建锁对象了~)

加锁场景

是否要加锁,怎么加锁,都是和具体场景直接相关的("无脑加锁"是不推荐的)

锁 ,需要的时候才使用,不需要的时候不要使用,否则会付出代价(性能)

使用锁,就可能会发生阻塞,一旦某个线程阻塞,啥时候恢复阻塞继续执行是不可预期的~

死锁

场景1

一个线程,针对一把锁,连续加锁两次

Java的synchronized做了特殊处理(引入了特殊机制,"可重入锁"),不会出现死锁,但同样的代码换成c++/python就会死锁

可重入锁就是在锁中额外记录一下当前是哪个线程,对哪个锁加锁了,后续加锁时就会进行判定

还会引入一个引用计数,维护当前已经加锁几次了,并且描述何时真正释放锁

场景2

两个线程,两把锁

线程1先针对A加锁,线程2针对B加锁
线程1不释放锁A的情况下,在针对B加锁,同时线程2不释放锁B的情况下对A加锁

这种情况,可重入锁也无能为力~

package thread;

public class Demo17 {
    private static Object locker1 = new Object();
    private static Object locker2 = new Object();

    public static void main(String[] args) {
        Thread t1 = new Thread(() -> {
            synchronized (locker1) {
                System.out.println("t1 加锁 locker1 完成");

                // 这里的 sleep 是为了确保, t1 和 t2 都先分别拿到 locker1 和 locker2 然后在分别拿对方的锁.
                // 如果没有 sleep 执行顺序就不可控, 可能出现某个线程一口气拿到两把锁, 另一个线程还没执行呢, 无法构造出死锁.
                try {
                    Thread.sleep(1000);
                } catch (InterruptedException e) {
                    throw new RuntimeException(e);
                }

                synchronized (locker2) {
                    System.out.println("t1 加锁 locker2 完成");
                }
            }
        });

        Thread t2 = new Thread(() -> {
            synchronized (locker2) {
                System.out.println("t2 加锁 locker2 完成");

                try {
                    Thread.sleep(1000);
                } catch (InterruptedException e) {
                    throw new RuntimeException(e);
                }

                synchronized (locker1) {
                    System.out.println("t2 加锁 locker1 完成");
                }
            }
        });

        t1.start();
        t2.start();
    }
}