一、线程中断、线程共享、线程封闭

一、6中线程状态定义：

java.lang.Thread.State

New、Runnable、Blocked、Waiting、Timed Waiting、Terminated

二、线程中止

不正确的线程终止方法：

1、stop(中止线程，清楚监控器锁的信息，但可能导致线程安全问题，JDK不建议使用：会导致线程的强行中断，导致代码块中的结果不可预测)、

2、destory(JDK并未实现该方法)

正确的线程中止方法：interrupt

1、目标线程被wait()、wait(long)阻塞时，使用interrupt，会抛出InterruptException

2、目标线程被join()、join(long)、sleep()阻塞时，使用interrupt，会抛出InterruptException

3、目标线程被I/O、NIO的channel阻塞时，使用interrupt，I/O会中断或返回特殊异常值

4、以上条件都不满足，会设置此线程的中断状态

三、线程通讯

1、文件共享

2、网络共享

3、变量共享

4、JDK提供的API：suspend/resume、wait/notify、park/unpark

重点：JDK提供的API：suspend/resume、wait/notify、park/unpark：

多线程协作的典型场景：生产者-消费者模型（线程阻塞、线程唤醒）

例子：线程1买包子，没有，阻塞；线程2生产包子，通知线程1执行

suspend/resume（弃用）

执行过程：通过suspend挂起线程，通过resume恢复

弃用原因：容易死锁

死锁场景：（本质还是不能保证执行顺序）

a、外部原因

1、suspend挂起线程后，不释放锁，resume执行前宕机

2、resume所在的生产者被优先线程调度，先释放，再suspend挂起，会导致死锁

b、内部原因

1、代码不规范，在调用resume之前尝试获取锁，此时锁已被suspend挂起

2、代码不规范，resume执行在suspend之前

wait/notify

1、规则：只能由同一对象锁的持有者线程执行，必须写在同步块里面，否则IllegalMonitorStateException

2、该组合对执行顺序由要求

3、存在线程一致阻塞的问题（先notify，在wait，内部原因，代码不规范）

park/unpark

1、park等待“许可 permit”，unpark提供“许可 permit”，不要求park和unpark的执行顺序

2、此处避免的wait/notify因为代码不规范导致的线程一直阻塞的问题，因为wait是线程持有者释放锁后，需唤醒才继续竞争锁，不唤醒则一直阻塞。而park则是线程不持有锁，是在等待令牌。

3、多次调用unpark之后，再调用park，线程会直接运行，因为park进入等待后发现有令牌了，直接运行，但不会叠加，连续多次调用park，第一次拿到许可后直接运行，后续调用会进入等待，因为令牌已经被第一次调用获取了，此时等待某处执行unpark命令。

4、但是park/unpark也会引起死锁，对顺序没有要求，但是不会释放锁

总结：

1、suspend/resume 获取锁，释放锁，因为多线程环境下的执行顺序问题导致死锁

2、wait/notify 释放锁，竞争锁，因为多线程环境下的执行顺序问题导致线程阻塞

3、使用令牌，而不是锁，此时park/unpark的执行不再以来执行顺序，很好的避免了死锁和线程阻塞

4、同步代码块中的park会导致死锁，注意！！

5、查看当前等待是否满足条件不可以用if，用while，上面的示例有误！原因：处于等待状态的线程可能会收到错误警报或伪唤醒，如果不是在循环中检查等待条件，程序会在没有满足结束条件的情况下退出。（伪唤醒是指线程并非因为notify、notifyall、unpark等api调用而唤醒，而是更底层的原因导致的）while会进行两次判断，if进行一次判断，出现伪唤醒会直接执行。

三、线程封闭与栈封闭

1、线程封闭

实现：ThreadLocal；并发环境中绝对安全；

注意：此时的threadlocal可以设置成全局变量，可以设置成static修饰，此时主线程和自己创建的线程对threadlocal的set、get是相互独立的。

原理：JVM维护了一个Map<Thread，T>，每个线程要用到这个T时，用当前的线程去Map里面取。

2、栈封闭

实现：局部变量；对应局部变量表

最后编辑于：2020.06.20 16:32:51