【JavaEE初阶】多线程（二）线程状态以及多线程安全问题

xxxflower

发布于 2023-04-27 16:18:53

5850

文章被收录于专栏：《数据结构》《数据结构》

线程的状态

状态是针对当前的线程调度的情况进行描述的。线程是调度的基本单位，状态是线程的属性。

NEW：创建了Thread对象，但是还没调用start（内核中还没有创建PCB）
TERMINATED：表示内核中的pcb已经执行完毕了，但是Thread对象还在。
RUNNABLE：可运行的（包括正在CPU上执行的和在就绪队列中随时可以去CPU上执行的）
WAITING
TIMED_WAITING
BLOCKED

4~6三个状态都是阻塞状态。（都是表示线程PCB正在阻塞队列中）只不过是不同原因的阻塞。

TERMINATED状态中，内核中线程的PCB被释放了，此时代码中的t对象也就没用了。Java中对象的生命周期自有其规则，这个生命周期和系统内核中的线程并非完全一致，**内核的线程释放的时候，无法保证Java代码中的t对象也立即释放。**此时t对象标识为：无效。虽然t对象无效了，但是t对象依旧可以完成调用函数等操作。一个线程只能start一次。

public class ThreadDemo10 {
    public static void main(String[] args) throws InterruptedException {
        Thread t = new Thread(()->{
            for (int i = 0; i < 100; i++) {
                for (int j = 0; j < 1000_0000; j++) {
                    int a = 10;
                    a += 10;
                }
            }
            try {
                Thread.sleep(10);
            } catch (InterruptedException e) {
                throw new RuntimeException(e);
            }
        });
        //未start之前是new状态
        System.out.println("start之前："+t.getState());
        t.start();
        //t执行中的状态runable
        for (int i = 0; i < 1000; i++) {
            System.out.println("t 执行中的状态: " + t.getState());
        }
        t.join();
        // 线程执行完毕之后, 就是 TERMINATED 状态
        System.out.println("t 结束之后: " + t.getState());
    }
}

多线程的意义：多线程可以更充分利用多核心的CPU资源，从而加快程序的运行效率。

多线程带来的风险

线程安全

线程安全的问题的根本原因就是抢占式执行，带来的随机性。 我们来看一个例子：

class Counter {
    public int count = 0;
     public void add() {
        count++;
    }
}

public class ThreadDemo12 {
    public static void main(String[] args) {
        Counter counter = new Counter();

        // 搞两个线程, 两个线程分别针对 counter 来 调用 5w 次的 add 方法
        Thread t1 = new Thread(() -> {
            for (int i = 0; i < 50000; i++) {
                counter.add();
            }
        });
        Thread t2 = new Thread(() -> {
            for (int i = 0; i < 50000; i++) {
                counter.add();
            }
        });
        // 启动线程
        t1.start();
        t2.start();

        // 等待两个线程结束
        try {
            t1.join();
            t2.join();
        } catch (InterruptedException e) {
            e.printStackTrace();
        }

        // 打印最终的 count 值
        System.out.println("count = " + counter.count);
    }
}

以上代码我们预期结果是100000次，但是运行结果如下：

为什么出现这个bug呢？ count++；本质上在操作系统中分成三步：

先把内存中的值，读取到CPU的寄存器上（load）
把CPU寄存器中的值进行+1操作。（add）
把读到的结果写到内存中。（save）

当两个线程并发执行count++时，就相当于load add save同时执行。此时就会产生结果上的差异。可能执行的方式：

箭头是时间轴，靠上就是先执行，靠下就是后执行。由于线程之间是随机调度的，导致此处的调度顺序充满其他可能性。

线程安全的原因

【根本原因】抢占式执行，随机调度
代码结构：多个线程同时修改一个变量。
原子性：如果修改操作是原子的，影响不是很大。但是如果是非原子的，出现问题的概率就会增加很多。
内存可见性问题
指令重排序（本质上是编译器优化出现了bug）：单个线程里，顺序发生调整。
…

要想解决线程安全问题，主要手段就是从原子性入手，把非原子的操作，变成原子的。加锁。

解决线程不安全问题（加锁）

上面我们说到。通过加锁，我们可以把不是原子的，转成原子的。

加了synchronized之后，进入add方法就会加锁，出了add方法就会解锁。如果两个线程同时尝试加锁，此时只有一个能获取锁成功，另一个只能阻塞等待（BLOCK）。一直阻塞到刚才的线程释放锁（解锁），当前线程才能加锁成功。

加锁，说是保证原子性，但并不是说让这里的三个操作一次性完成，也不是这三步操作过程中不进行调度，而是让其他也想操作的线程阻塞等待。加锁本质上是把并发变成了并行。 加锁操作会影响程序的速率，在实际过程中我们要通过实际情景来对其进行合理加锁。

synchronized使用方法：

修饰方法（1）修饰普通方法（锁对象是this）（2）修饰静态方法（锁对象是类对象（Counter.class））
修饰代码块（显示/手动指定锁对象）

加锁，要明确执行对哪个对象进行加锁的。如果两个线程针对同一个对象加锁，会产生阻塞等待。（锁竞争/锁冲突）如果两个对象针对不同对象加锁，不会参数阻塞等待。（不会锁竞争/锁冲突） 一定要注意锁对象是哪个！

synchronized关键字-监视器锁monitor lock

监视器锁也就是synchronized。有时会在异常中看到这个词。

synchronized的特性

互斥 synchronized 会起到互斥效果, 某个线程执行到某个对象的 synchronized 中时, 其他线程如果也执行到同一个对象 synchronized 就会阻塞等待.

进入 synchronized 修饰的代码块, 相当于加锁
退出 synchronized 修饰的代码块, 相当于解锁

理解 “阻塞等待”：针对每一把锁, 操作系统内部都维护了一个等待队列. 当这个锁被某个线程占有的时候, 其他线程尝试进行加锁,就加不上了, 就会阻塞等待, 一直等到之前的线程解锁之后, 由操作系统唤醒一个新的线程, 再来获取到这个锁。注意：上一个线程解锁之后, 下一个线程并不是立即就能获取到锁. 而是要靠操作系统来 “唤醒”. 这也就是操作系统线程调度的一部分工作. 假设有 A B C 三个线程, 线程 A 先获取到锁, 然后 B 尝试获取锁, 然后 C 再尝试获取锁, 此时 B和 C 都在阻塞队列中排队等待. 但是当 A 释放锁之后, 虽然 B 比 C 先来的, 但是 B 不一定就能获取到锁, 而是和 C 重新竞争, 并不遵守先来后到的规则.

可重入 synchronized 同步块对同一条线程来说是可重入的，不会出现自己把自己锁死的问题；也就是说，一个线程针对同一个对象，连续加锁两次，是否会有问题。如果没问题就叫做可重入，如果有问题就叫做不可重入的。

上述代码中，锁对象是this，只要有线程调用add，进入add方法的时候，就会先加锁。进入add方法时，又遇到了代码块，再次尝试加锁。站在this的角度看（锁对象），自己已经被另外的线程占用了，第二次的加锁是否要阻塞等待呢？如果允许上述操作，这个锁就是可重入的。如果不允许，就是不可重入的。就会产生死锁

java中的死锁问题

死锁

程序中一旦出现死锁，就会导致线程崩溃了（无法继续执行后续工作）。程序就会产生严重的bug。死锁一般是非常隐蔽的。

死锁的三个典型情况

一个线程，一把锁，连续加锁两次。如果锁是不可重入锁，就会死锁 java中synchronized和ReentrantLock都是可重入锁。
两个线程两把锁，t1和t2各自先针对锁A和锁B加锁。再尝试获取对方的锁。举个例子：某人把家里钥匙锁在了车里，把车钥匙锁在了家里；小红写完了英语作业，想要抄小兰的数学作业，小兰写完了数学作业，想要抄小红的英语作业。但是两人都不开口。这个场景就僵住了~

public class ThreadDemo13 {
    public static void main(String[] args) {
        Object yingyu = new Object();
        Object shuxue = new Object();

        Thread xiaohong = new Thread(() -> {
            synchronized (yingyu) {

                try {
                    Thread.sleep(1000);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }

                synchronized (shuxue) {
                    System.out.println("小红抄到了小兰的数学作业！小红写完了所有作业。");
                }
            }
        });
        Thread xiaolan = new Thread(() -> {
            synchronized (shuxue) {

                try {
                    Thread.sleep(1000);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }

                synchronized (yingyu) {
                    System.out.println("小兰抄到了小红的英语作业！小兰写完了所有作业。");
                }
            }
        });
        xiaohong.start();
        xiaolan.start();
    }
}

通过运行结果可知，此时没有线程拿到两把锁。

BLOCK表示获取锁，获取不到阻塞状态。 java：16行

java:32

针对这样的死锁问题，需要借助jconsole这样的工作来进行定位，看线程的状态和调用栈。就可以分析代码再哪里死锁了。

多个线程多把锁。经典案例：哲学家就餐问题

每个哲学家有两种状态： 1.思考人生（相当于线程阻塞状态） 2.拿起筷子吃面条（相当于线程获取到所然后执行一些计算的状态）由于系统的随机操作，这五个哲学家，随时都可能想吃面条，也随时都有可能要思考人生。想要吃面条就需要拿起左手和右手两根筷子。假设出现了极端情况就会死锁，即同一时刻，所有哲学家同时拿起左手的筷子，都要等待右边的哲学家把筷子放下。那么如何解决这个问题呢？编号（给筷子编号）。先拿编号小的，再拿编号大的。

这样一来，A先拿1，B先拿2,C先拿3，D先拿4，E先拿1。此时E就必须等待A使用完1，再拿起5吃面。E吃完D使用5和4吃… 这样就解决了死锁问题。

public class ThreadDemo13 {
    public static void main(String[] args) {
        Object yingyu = new Object();
        Object shuxue = new Object();

        Thread xiaohong = new Thread(() -> {
            // 假设 yingyu 是 1 号, shuxue 是 2 号, 约定先拿小的, 后拿大的.
            synchronized (yingyu) {

                try {
                    Thread.sleep(1000);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }

                synchronized (shuxue) {
                    System.out.println("小红抄到了小兰的数学作业！小红写完了所有作业。");
                }
            }
        });
        Thread xiaolan = new Thread(() -> {
            synchronized (yingyu) {

                try {
                    Thread.sleep(1000);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }

                synchronized (shuxue) {
                    System.out.println("小兰抄到了小红的英语作业！小兰写完了所有作业。");
                }
            }
        });
        xiaohong.start();
        xiaolan.start();
    }
}

死锁的四个必要条件

互斥使用：线程1拿到了锁，线程2就等待。
不可抢占：线程1拿到锁之后，必须是线程1主动释放，线程2不能强制获取。
请求和保持：线程1拿到锁A之后，再尝试获取锁B，A这把锁还是保持的。
循环等待：线程1尝试获取到锁A和锁B 线程2尝试获取到锁B和锁A；线程1在获取B的时候等待线程2释放B，同时线程2在获取锁A的时候等待线程1释放锁A；

如何避免死锁？

如何避免死锁？（以循环等待为突破口）方法：给锁编号，然后指定一个固定的顺序（从小到大）来加锁，任意线程加多把锁的时候，都让线程遵守上述顺序，此时循环等待自然破除。这是解决死锁最简单可靠的办法。

Java 标准库中的线程安全类

Java 标准库中很多都是线程不安全的. 这些类可能会涉及到多线程修改共享数据, 又没有任何加锁措施.

ArrayList
LinkedList
HashMap
TreeMap
HashSet
TreeSet
StringBuilder

但是还有一些是线程安全的. 使用了一些锁机制来控制.

Vector (不推荐使用)
HashTable (不推荐使用）
ConcurrentHashMap
StringBuffer

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

String

本文参与腾讯云自媒体同步曝光计划，分享自作者个人站点/博客。

原始发表：2023-04-21，如有侵权请联系 cloudcommunity@tencent.com 删除

对象