初始JavaEE篇——多线程（2）：join的用法、线程安全问题

找往期文章包括但不限于本期文章中不懂的知识点：

个人主页：我要学编程(ಥ_ಥ)-CSDN博客

所属专栏：JavaEE

模拟实现线程中断

join的用法

线程的状态

NEW：

RUNNABLE：

TIMED_WAITING：

TERMINATED：

线程安全问题

现象

原因

解决

初始JavaEE篇——多线程（1）：Thread类的介绍与使用-CSDN博客

我们在上一篇文章中学习创建线程，观察线程状态，以及线程的常用属性和方法。最后，我们学到了中断线程，并且也演示了如何去中断一个线程，关键是提早结束run方法，我们使用了两个方法 interrupted 和 interrupt，前者判断是否是被中断，后者是去中断线程的。线程是否被中断，主要是看线程的中断标志位是被修改为 true。先前我们是通过Java提供的来实现的，现在我们需要自己来模拟实现标志位的功能。

模拟实现线程中断

思路：定义一个布尔类型的变量表示当前线程是否中断。当 t线程执行一段时间之后，我们在main线程中去修改 t 线程的中断标志位即可。

代码演示：

public class Test {
    public static boolean isFinished = false;
    public static void main(String[] args) throws InterruptedException {
        Thread t = new Thread(()->{
           while (!isFinished) {
               System.out.println("Hello Thread");
               try {
                   Thread.sleep(1000);
               } catch (InterruptedException e) {
                   throw new RuntimeException(e);
               }
           }
            System.out.println("t线程结束");
        });
        // 启动 t线程，并调用run方法
        t.start();
        for (int i = 0; i < 3; i++) {
            System.out.println("Hello main");
            Thread.sleep(1000);
        }
        isFinished = true;
        Thread.sleep(1000);
        System.out.println("main线程结束");
    }
}

运行结果：

上面的标志位是成员变量，如果我们设置成局部变量就会发现代码有语法错误。

这里涉及到了一个关于lambda表达式的知识点：

先来解释，局部变量为什么在lambda表达式中使用会报错的原因：

1、lambda表达式在访问局部变量时，采用了"变量捕获"的语法，其的做法是将这个变量拷贝了一份到属于自己的内存空间中，当其去使用这个变量时，直接去拿拷贝的即可，虽然这样会很方便，但是也有问题：

1）当被拷贝的变量，发生变化时，lambda表达式里面的代码在使用时，是感受不到的，因此就会产生无法预料的错误；

2）当拷贝的变量被销毁了，但是lambda表达式里面的代码还需要使用时，会造成内存访问异常；

由于上面两种情况，因此Java中就规定了：lambda表达式中使用的局部变量要么是强制的 final 类型，要么是理论上的 final 类型。理论上的 final 类型是指当虽然这个变量没有被 final 修饰，但是这个变量在整个进程中并没有没修改过的痕迹，也就是没有代码会去修改这个变量。

2、成员变量在lambda表达式中被使用时，是用了内部类访问外部类的语法，而不是变量捕获的语法了。因此使用成员变量是没有问题的。

可能还有小伙伴会觉得：为什么把 static 去掉，程序就会编译错误呢？难道内部类不能直接访问外部类的成员变量吗？是可以直接访问的，但是根据成员变量的不同，就有对应的不同情况了。静态成员变量，在内部类中需要用 " 类名. "来访问的，而在lambda表达式中却可以省略，直接访问静态成员变量，但是非静态的就需要实例化对象了。

join的用法

join 是用来等待一个线程的。例如，当在 main 线程中，t 线程调用 join方法时，效果是 main 线程等待 t 线程，当 t 线程执行完毕之后，main 线程才会从阻塞中重新进入运行。

代码演示：

public class Test {
    public static void main(String[] args) throws InterruptedException {
        Thread t = new Thread(()->{
            for (int i = 0; i < 3; i++) {
                System.out.println("Hello Thread");
                try {
                    Thread.sleep(1000);
                } catch (InterruptedException e) {
                    throw new RuntimeException(e);
                }
            }
            System.out.println("t线程结束");
        });
        // 启动 t线程，并调用run方法
        t.start();
        // 我们想让t线程先执行，main线程后执行
        t.join();
        for (int i = 0; i < 3; i++) {
            System.out.println("Hello main");
            Thread.sleep(1000);
        }
        System.out.println("main线程结束");
    }
}

运行结果：

当然，可以有小伙伴认为sleep方法也能得到上述的效果。确实sleep方法可以实现上述的效果，但是sleep方法要我们人为的去设置参数，有些不方便，因此我们就使用 join方法。

《等你》

站在岁月的桥头等你，
看流水匆匆，时光悠悠。
风拂过发梢，思念在心头，
等待你的身影，出现在眼眸。

花开花落，四季轮流，
心从未更改，那份执着依旧。
等你归来，共赴那一场温柔，
让等待的时光，绽放成最美的守候。

虽然上面的句子表达很美，但是在编程的世界里面，这种做法很不合理，因此 join 方法也有参数的重载版本，这个参数是表示最大的等待时间，当超过这个等待时间时，等待的线程也就自动醒来继续执行了。这个参数同样是毫秒级别的。

演示：

线程的状态

在前面学习操作系统时，我们知道了进程的五种状态：创建态、就绪态、运行态、阻塞态、结束态。同样线程也是有上述的五种状态，但是在站在Java的角度来看的话，JVM都是帮我们进行了分装的。有如下几种：

操作系统对应的状态	Java中对应的状态（JVM封装之后）	解释说明
创建态	NEW	安排了工作，还未开始行动
就绪态	RUNNABLE	即将开始工作
运行态	RUNNABLE	正在工作中
阻塞态哦（资源等待）	WAITING	排队等待其他事情
阻塞态（同步等待）	BLOCKED	排队等待其他事情
阻塞态（定时等待）	TIMED_WAITING	排队等待其他事情
结束态	TERMINATED	工作完成了

我们也可以通过代码来观察这些状态：

NEW：

已经实例化了线程对象，但是还没有启动线程。

RUNNABLE：

1）、刚启动了线程，已经准备就绪了；2）、线程已经开始工作了。

由于线程是并发执行，并且随机调度的，因此 t线程和 main线程都是谁先执行，谁后执行是不能区分的，因此我们只能打印出RUNNABLE，但是不能区分具体是啥状态。

TIMED_WAITING：

由于计时，引起的阻塞：

同步阻塞和资源阻塞在很多情况下可能是因为锁的问题，这个我们后面再学习。

TERMINATED：

线程已经完成工作，被销毁了。

线程安全问题

现象

前面学习的都是现成带来了好处，而实际开发中，如果不仔细的话，是很容易写出线程不安全的代码的。例如，下面这样的代码：

public class Test {
    private static int count = 0;

    public static void main(String[] args) throws InterruptedException {

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

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

        t1.start();
        t2.start();
        // 先得让 t1和t2线程全部执行完毕
        t1.join(); // main线程等待 t1线程
        t2.join(); // main线程等待 t2线程
        System.out.println(count);
    }

}

最终的运行结果一定是不会达到 200000 的。这里就是由多线程导致的线程安全问题。我们也可以去证明：

t1.start();
t1.join(); // main线程等待 t1线程，并且 t2此时也不会执行

t2.start();
t2.join(); // main线程等待 t2线程，t1线程已经执行完毕
System.out.println(count);

上面代码的最终逻辑就是先执行 t1 线程，再执行 t2 线程，最后的结果就是串行执行的结果。

注意：for循环的循环次数过少，可能会出现这样的情况：t1线程在一个时间片内，其run方法就已经执行完了，那么就不会出现并发的效果了，就相当于是在串行执行。

原因

造成线程安全问题的原因主要有以下几点：

1、根本原因：随机调度，抢占式执行。

我们写的代码，最终都是会转为计算机指令，让CPU去执行的，由于时间片的存在，当前线程的时间片执行完毕时，该线程就会被操作系统强制踢下CPU，让后面需要执行的线程上CPU开始执行，而上一次被踢下CPU时，可能还没有执行完 count++ 操作（这个操作对应三个计算机指令），导致两次 ++ 的结果可能会重合、覆盖，导致最终 "少加了"

2、多个线程同时修改同一个变量。

如果是多个线程访问同一个变量，而不去修改的话，不会出现上述的情况。

如果是一个线程修改一个变量，就不会出现上述的情况。我们学习多线程之前，就是只有main线程在同一时刻修改同一个变量。

如果是多个线程分时修改同一个变量，也不会出现上述情况。例如，先让 t1 线程修改，再让 t2 线程修改，最终的结果就是正确的。

如果是多个线程同时修改不同的变量，也不会出现上述情况。例如，t1 线程修改 count1 变量，t2 线程修改 count2 变量，即使操作系统 "故意" 把指令打散，但是因为只有一个线程去修改，最终也不会出现少修改的情况。如下代码：

public class Test {
    private static int count1 = 0;
    private static int count2 = 0;

    public static void main(String[] args) throws InterruptedException {

        Thread t1 = new Thread(() -> {
            for (int i = 0; i < 100000; i++) {
                count1++;
            }
        });

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

        t1.start();
        t2.start();
        // 先得让 t1和t2线程全部执行完毕
        t1.join(); // main线程等待 t1线程
        t2.join(); // main线程等待 t2线程
        System.out.println(count1);
        System.out.println(count2);
    }
}

3、修改操作不是原子的。

count++ 这个操作站在 CPU指令的角度是分为三个步骤，这也给了操作系统的可乘之机，使其去随机调度，让正在修改的线程，从CPU上被踢了下去。

4、内存可见性。

5、指令重排序。

4 和 5 这两种情况，我们后期再学习。

解决

我们已经知道了上面的原因，接下来就可以开始针对原因进行修改了。1、2 肯定是不可以被改变的，因此我们只能让 count++ 的指令操作变为原子性，即进行加锁操作。

将 count++ 的操作进行加锁，使得同一时刻只能有一个线程去访问并且修改。使用 synchronized 关键字进行加锁操作。

语法：

synchronized(locker) {
    ... // 要加锁的操作
}

// locker 是锁对象，这个确保了同一时刻只能有一个线程访问当中的代码块

代码演示：

public class Test {
    private static int count = 0;
    public static void main(String[] args) throws InterruptedException {
        Object locker = new Object(); // 锁对象 —— 只要是一个对象即可
        Thread t1 = new Thread(()->{
            // 当t1线程执行到下面的代码时，t2线程只能阻塞等待t1线程执行完毕（for循环结束）
            synchronized(locker) {
                for (int i = 0; i < 100000; i++) {
                    count++;
                }
            }
        });

        Thread t2 = new Thread(()->{
            // 当t2线程执行到下面的代码时，t1线程只能阻塞等待t2线程执行完毕（for循环结束）
            synchronized(locker) {
                for (int i = 0; i < 100000; i++) {
                    count++;
                }
            }
        });

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

        t1.join(); // 这里只有t1线程在执行
        t2.join(); // 这里只有t2线程在执行

        System.out.println(count);
    }
}

上面的代码最终执行的结果是：200000 。这里解决的是修改操作原子性的问题。强制性的确保了操作系统调度 t2线程时，由于t1线程对locker对象进行了加锁操作，t2线程不能够执行 synchronized 代码块，也就不可以去修改了count了。最终达到了串行执行的效果。

除了上面这种对for循环整体进行加锁操作之外，还可以只对 count++ 操作进行加锁，因为 count++ 才是最终的修改操作。

public class Test {
    private static int count = 0;

    public static void main(String[] args) throws InterruptedException {
        Object locker = new Object(); // 锁对象 —— 只要是一个对象即可
        Thread t1 = new Thread(()->{
            for (int i = 0; i < 100000; i++) {
                // 当t1线程执行到下面的代码时，
                // t2线程只能阻塞等待t1线程执行完毕（出synchronized代码块）
                synchronized (locker) {
                    count++;
                }
            }
            
        });

        Thread t2 = new Thread(()->{
            for (int i = 0; i < 100000; i++) {
                // 当t2线程执行到下面的代码时，
                // t1线程只能阻塞等待t2线程执行完毕（出synchronized代码块）
                synchronized (locker) {
                    count++;
                }
            }
        });

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

        t1.join(); // 这里只有t1线程在执行
        t2.join(); // 这里只有t2线程在执行

        System.out.println(count);
    }
}

第二种写法由于只对 count++ 操作进行加锁，因此也就只有这个操作是串行执行，for循环的其他部分是并行执行，这比起让for循环整体串行操作，这个的效率明显要高一些。

注意：

1、加锁操作之所以可以确保多线程代码的安全性，是因为线程之间对锁的访问是互斥的。即当一个线程拿到锁之后，另一个线程再去尝试拿锁时，就会因为互斥从而拿锁失败。

2、多个线程加锁的对象必须是同一个才行。如果说多个线程对不同的对象进行加锁操作的话，那么达不到锁本身的互斥效果。因为只有一个线程拿到了，没有多个线程去尝试加锁。

synchronized 除了可以对代码块进行加锁操作之外，还能够对方法进行加锁操作。与对代码块一样，只要加了锁的，当有多个线程来访问时，都会发生互斥，只有最先拿到的线程才可以执行方法，后面的线程会阻塞等待。

代码演示：

class Counter{
    private int count;

    // 当t1线程执行到下面的代码时，t2线程只能阻塞等待t1线程执行完毕（方法执行完）
    public synchronized void add() {
        count++;
    }

    public int get() {
        return count;
    }
}

public class Test {
    public static void main(String[] args) throws InterruptedException {
        Counter counter = new Counter();
        Thread t1 = new Thread(()->{
            for (int i = 0; i < 100000; i++) {
                counter.add();
            }
        });

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

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

        t1.join(); // 这里只有t1线程在执行
        t2.join(); // 这里只有t2线程在执行

        System.out.println(counter.get());
    }
}

对静态方法进行加锁，类似于对类对象进行加锁；对实例方法进行加锁，类似于对this进行加锁。

好啦！本期初始JavaEE篇——多线程（2）：join的用法、线程安全问题的学习之旅到此结束啦！我们下一期再一起学习吧！