JUC（一）

通过本文档你将学习到

• 进程
• 线程
• 并发
• 并行
• java常用的并发工具，并发问题以及解决方案

1 概述

本次分享主要讲述JUC的一些相关知识，这些知识会在平时工作中用到，面试的时候也是必问的。通过本文档的学习，你大概清楚

本次主要都是讲述理论知识，理论也很重要，不要轻视，面试的时候也会问你的。问你什么是线程？什么是进程？你说继承什么什么类，什么什么的。就那，就那意思。那不就GG了。

1.1 什么是JUC

在 Java 中，线程部分是一个重点，本篇文章说的 JUC 也是关于线程的。JUC
就是 java.util .concurrent 工具包的简称。这是一个处理线程的工具包，JDK
1.5 开始出现的。

1.2 进程、线程、管程

1.线程是程序执行的最小单位，而进程是操作系统分配资源的最小单位;
2.一个进程由一个或多个线程组成，线程是一个进程中代码的不同执行路线;
3.进程之间相互独立，但同一进程下的各个线程之间共享程序的内存空间(包括代码段、数据集、堆等)及一些进程级的资源(如打开文件和信号)，某进程内的线程在其它进程不可见;
4.调度和切换：线程上下文切换比进程上下文切换要快得多；
5.进程和线程都是由操作系统内核所管理。

为线程的容器

简单说：以上都是书本官方语言。一个360杀毒软件打开就是一个进程，你既可以扫描垃圾，同时也可以杀毒。开启了两个线程。大致意思如此。

两者的对比

• 进程基本上相互独立的，而线程存在于进程内，是进程的一个子集
• 进程拥有共享的资源，如内存空间等，供其内部的线程共享
• 进程间通信较为复杂
  同一台计算机的进程通信称为 IPC（Inter-process communication）
  不同计算机之间的进程通信，需要通过网络，并遵守共同的协议，例如 HTTP
• 线程通信相对简单，因为它们共享进程内的内存，一个例子是多个线程可以访问同一个共享变量
• 线程更轻量，线程上下文切换成本一般上要比进程上下文切换低

管程就是我们平时说的锁
monitor监视锁

1.3 并行和并发

单核 cpu 下，线程实际还是 串行执行 的。操作系统中有一个组件叫做任务调度器，将 cpu 的时间片（windows
下时间片最小约为 15 毫秒）分给不同的程序使用，只是由于 cpu 在线程间（时间片很短）的切换非常快，人类感
觉是 同时运行的 。总结为一句话就是： 微观串行，宏观并行 ，
一般会将这种 线程轮流使用 CPU 的做法称为并发， concurrent

单核

多核 cpu下，每个 核（core） 都可以调度运行线程，这时候线程可以是并行的。

多核

简单说：
家庭主妇做饭、打扫卫生、给孩子喂奶，她一个人轮流交替做这多件事，这时就是并发
家庭主妇雇了个保姆，她们一起这些事，这时既有并发，也有并行（这时会产生竞争，例如锅只有一口，一
个人用锅时，另一个人就得等待）
雇了3个保姆，一个专做饭、一个专打扫卫生、一个专喂奶，互不干扰，这时是并行

1.4 线程的状态

这是从 操作系统 层面来描述的

线程状态

• 【初始状态】仅是在语言层面创建了线程对象，还未与操作系统线程关联
• 【可运行状态】（就绪状态）指该线程已经被创建（与操作系统线程关联），可以由 CPU 调度执行
• 【运行状态】指获取了 CPU 时间片运行中的状态
  当 CPU 时间片用完，会从【运行状态】转换至【可运行状态】，会导致线程的上下文切换
• 【阻塞状态】
  如果调用了阻塞 API，如 BIO 读写文件，这时该线程实际不会用到 CPU，会导致线程上下文切换
• 【阻塞状态】
  等 BIO 操作完毕，会由操作系统唤醒阻塞的线程，转换至【可运行状态】
  与【可运行状态】的区别是，对【阻塞状态】的线程来说只要它们一直不唤醒，调度器就一直不会考虑
  调度它们
• 【终止状态】表示线程已经执行完毕，生命周期已经结束，不会再转换为其它状态

这是从 Java API 层面来描述的
根据 Thread.State 枚举，分为六种状态

Java API.png

• NEW 线程刚被创建，但是还没有调用 start() 方法
• RUNNABLE 当调用了 start() 方法之后，注意，Java API 层面的 RUNNABLE 状态涵盖了 操作系统 层面的
  【可运行状态】、【运行状态】和【阻塞状态】（由于 BIO 导致的线程阻塞，在 Java 里无法区分，仍然认为是可运行）
• BLOCKED ， WAITING ， TIMED_WAITING 都是 Java API 层面对【阻塞状态】的细分
• TERMINATED 当线程代码运行结束

BLOCKED

Java文档官方定义BLOCKED状态是：“这种状态是指一个阻塞线程在等待monitor锁。”

真实生活例子：今天你要去面试。这是你梦想的工作，你已经盯着它多年了。你早上起来，准备好，穿上你最好的外衣，对着镜子打理好。当你走进车库发现你的老婆已经把车开走了。在这个场景，你只有一辆车，所以怎么办？在真实生活中，可能会打架:-)。 现在因为你老爸把车开走了你被BLOCKED了。你不能去参加面试。

这就是BLOCKED状态。用技术术语讲，你是线程T1，你老婆是线程T2而锁是车。T1被BLOCKED在锁（例子里的车）上，因为T2已经获取了这个锁。

小贴士：当线程调用Object#wait()方法进入一个synchronized块/方法或重进入一个synchronized锁/方法时会等待获取monitor锁。

WAITING

Java文档官方定义WAITING状态是：“一个线程在等待另一个线程执行一个动作时在这个状态”

真实生活例子：再看下几分钟后你的老婆开车回家了。现在你意识到快到面试时间了，而开车过去很远。所以你拼命地踩油门。限速120KM/H而你以160KM/H的速度在开。很不幸，一个交警发现你超速了，让你停到路边。现在你进入了WAITING状态。你听下车坐在那等着交警过来检查你并放行。基本上，只有等他让你走，你被卡在WAITING状态了。

用技术术语来讲，你是线程T1而交警是线程T2。你释放你的锁（例子中你停下了车），并进入WAITING状态，直到警察（例子中T2）让你走，你陷入了WAITING状态。

小贴士：当线程调用以下方法时会进入WAITING状态：

1. Object#wait() 而且不加超时参数

2. Thread#join() 而且不加超时参数

3. LockSupport#park()

在对象上的线程调用了Object.wait()会进入WAITING状态，直到另一个线程在这个对象上调用了Object.notify()或Object.notifyAll()方法才能恢复。一个调用了Thread.join()的线程会进入WAITING状态直到一个特定的线程来结束。

TIMED_WAITING

Java文档官方定义TIMED_WAITING状态为：“一个线程在一个特定的等待时间内等待另一个线程完成一个动作会在这个状态”

真实生活例子：尽管充满戏剧性，你在面试中做的非常好，惊艳了所有人并获得了高薪工作。（祝贺你！）你回家告诉你的邻居你的新工作并表达你激动的心情。你的朋友告诉你他也在同一个办公楼里工作。他建议你坐他的车去上班。你想这不错。所以第一天，你走到他的房子。在他的房子前停好你的车。你等了10分钟，但你的邻居没有出现。你继续开自己的车去上班，这样你不会在第一天就迟到。这就是TIMED_WAITING.

用技术术语来解释，你是线程T1而你的邻居是线程T2。你释放了锁（这里是停止开车）并等了足足10分钟。如果你的邻居T2没有来，你继续开车。

小贴士：调用了以下方法的线程会进入TIMED_WAITING：

1. Thread#sleep()

2. Object#wait() 并加了超时参数

3. Thread#join() 并加了超时参数

4. LockSupport#parkNanos()

5. LockSupport#parkUntil()

1.4.1 小知识

wait/sleep 的区别

• sleep 是 Thread 的静态方法，wait 是 Object 的方法，任何对象实例都能调用。
• sleep 不会释放锁，它也不需要占用锁。wait 会释放锁，但调用它的前提
  是当前线程占有锁(即代码要在 synchronized 中)。
• 它们都可以被 interrupted 方法中断。

1.5 常见的线程API

常见的线程API

1.6 部分方法讲解

打断标记默认就是false

isInterrupted
判断是否被打断 不会清除标记。
interrupt()
打断睡眠中的会抛异常，并且清除打断标记
interrupted（）
1、判断是否被打断
2、清除打断标记。

这里还要在介绍一个方法就是park unpark

方法区别总结

这里还要在介绍一个方法就是park unpark

park函数是将当前调用Thread阻塞，而unpark函数则是将指定线程Thread唤醒。
与Object类的wait/notify机制相比，park/unpark有两个优点：
以thread为操作对象更符合阻塞线程的直观定义操作更精准，可以准确地唤醒某一个线程（notify随机唤醒一个线程，notifyAll唤醒所有等待的线程），增加了灵活性。
关于“许可”
其实park/unpark的设计原理核心是“许可”：park是等待一个许可，unpark是为某线程提供一个许可。
如果某线程A调用park，那么除非另外一个线程调用unpark(A)给A一个许可，否则线程A将阻塞在park操作上。

• 有一点比较难理解的，是unpark操作可以再park操作之前。也就是说，先提供许可。当某线程调用park时，已经有许可了，它就消费这个许可，然后可以继续运行。这其实是必须的。

考虑最简单的生产者(Producer)消费者(Consumer)模型：Consumer需要消费一个资源，于是调用park操作等待；Producer则生产资源，然后调用unpark给予Consumer使用的许可。非常有可能的一种情况是，Producer先生产，这时候Consumer可能还没有构造好（比如线程还没启动，或者还没切换到该线程）。那么等Consumer准备好要消费时，显然这时候资源已经生产好了，可以直接用，那么park操作当然可以直接运行下去。如果没有这个语义，那将非常难以操作。所以只要我们的 park/unpark 成对出现，无论执行顺序如何，都不会因此造成死锁但是这个“许可”是不能叠加的，“许可”是一次性的。比如线程B连续调用了三次unpark函数，当线程A调用park函数就使用掉这个“许可”，如果线程A再次调用park，则进入等待状态。

• park不需要获取某个对象的锁

• 因为中断的时候park不会抛出InterruptedException异常，所以需要在park之后自行判断中断状态，然后做额外的处理。

• 如果打断标记已经是 true, 则 park 会失效

简单说：
每个线程都有自己的一个 Parker 对象，由三部分组成 _counter ， _cond 和 _mutex 打个比喻
线程就像一个旅人，Parker 就像他随身携带的背包，条件变量就好比背包中的帐篷。_counter 就好比背包中
的备用干粮（0 为耗尽，1 为充足）

调用 park 就是要看需不需要停下来歇息
如果备用干粮耗尽，那么钻进帐篷歇息
如果备用干粮充足，那么不需停留，继续前进
调用 unpark，就好比令干粮充足
如果这时线程还在帐篷，就唤醒让他继续前进
如果这时线程还在运行，那么下次他调用 park 时，仅是消耗掉备用干粮，不需停留继续前进
因为背包空间有限，多次调用 unpark 仅会补充一份备用干粮

1.7 interrupt()、interrupted()和isInterrupted()方法的应用

扯了这么多，有啥用，面试用工作用呗。停止线程你准备怎么做？我知道直接stop,类似于不看电视了，直接把电源拔了，太暴力，你得给人家缓冲时间吧？疫情来了，通知你隔离，是不是接收到通知后，你得收拾下东西干嘛的。

这个模式叫做两阶段终止模式

1. 错误思路

• 使用线程对象的 stop() 方法停止线程
  stop 方法会真正杀死线程，如果这时线程锁住了共享资源，那么当它被杀死后就再也没有机会释放锁，
  其它线程将永远无法获取锁

• 使用 System.exit(int) 方法停止线程
  目的仅是停止一个线程，但这种做法会让整个程序都停止
  2 两阶段终止模式

  
  
  两阶段终止模式.png

interrupt 可以打断正在执行的线程，无论这个线程是在 sleep，wait，还是正常运行

package cn.itcast.pattern;

import lombok.extern.slf4j.Slf4j;

@Slf4j(topic = "c.TestTwoPhaseTermination")
public class TestTwoPhaseTermination {
    public static void main(String[] args) throws InterruptedException {
        TPTInterrupt t = new TPTInterrupt ();
        t.start();

        Thread.sleep(3500);
        log.debug("stop");
        t.stop();
    }
}
@Slf4j(topic = "c.TPTInterrupt")
class TPTInterrupt {
    private Thread thread;

    public void start(){
        thread = new Thread(() -> {
            while(true) {
                Thread current = Thread.currentThread();
                if(current.isInterrupted()) {
                    log.debug("料理后事");
                    break;
                }
                try {
                    Thread.sleep(1000);
                    log.debug("查询数据库看看有没有变化，巴拉巴拉巴拉");
                } catch (InterruptedException e) {
                    current.interrupt();
                }

            }
        },"监控线程");
        thread.start();
    }

    public void stop() {
        thread.interrupt();
    }
}
@Slf4j(topic = "c.TPTVolatile")
class TPTVolatile {
    private Thread thread;
    private volatile boolean stop = false;

    public void start(){
        thread = new Thread(() -> {
            while(true) {
                Thread current = Thread.currentThread();
                if(stop) {
                    log.debug("料理后事");
                    break;
                }
                try {
                    Thread.sleep(1000);
                    log.debug("将结果保存");
                } catch (InterruptedException e) {
                }
            }
        },"监控线程");
        thread.start();
    }

    public void stop() {
        stop = true;
        thread.interrupt();
    }
}

11:49:42.915 c.TwoPhaseTermination [监控线程] - 将结果保存
11:49:43.919 c.TwoPhaseTermination [监控线程] - 将结果保存
11:49:44.919 c.TwoPhaseTermination [监控线程] - 将结果保存
11:49:45.413 c.TestTwoPhaseTermination [main] - stop 
11:49:45.413 c.TwoPhaseTermination [监控线程] - 料理后事