初始JavaEE篇——多线程（1）：Thread类的介绍与使用
我们在上一篇文章中学习创建线程，观察线程状态，以及线程的常用属性和方法。最后，我们学到了中断线程，并且也演示了如何去中断一个线程，关键是提早结束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的用法、线程安全问题 的学习之旅到此结束啦！我们下一期再一起学习吧！
