一、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、栈封闭
实现：局部变量；对应局部变量表
网友评论