一、线程的状态
1.NEW Thread：对象创建好了，但是还没有调用 start 方法在系统中创建线程。
2.TERMINATED： Thread 对象仍然存在,但是系统内部的线程已经执行完毕了。
3.RUNNABLE： 就绪状态，表示这个线程正在 cpu 上执行,或者准备就绪随时可以去 pu 上执行。
4.TIMED WAITING： 指定时间的阻塞.就在到达一定时间之后自动解除阻塞使用 sleep 会进入这个状态 使用带有超时时间的join也会。
5.WAITING： 不带时间的阻塞(死等)，必须要满足一定的条件,才会解除阻塞join 或者 wait 都会进入 WAITING。
6.BLOCKED： 由于锁竞争,引起的阻塞.(后面线程安全的时候具体介绍)
这六种状态在生命周期的大概位置，如图：
用代码形式测试 NEW 、RUNNABLE、TERMINATED 状态
代码：
public class ThreadDemo3 { private static int count = 0; public static void main(String[] args) throws InterruptedException { Thread t = new Thread(() -> { for (int i = 0; i < 5000; i++) { count++; } System.out.println("count: " + count); }); //t线程开始前 System.out.println("t线程开始前: " + t.getState()); t.start(); //t线程执行中 System.out.println("t线程执行中: " + t.getState()); //t线程结束后 t.join(); System.out.println("t线程结束后: " + t.getState()); } }
执行效果：
学习这些状态，最大的作用就是调试多线程代码bug的时候，给我们提供重要的参考依据，当某个程序卡住了，也就是意味着一些关键的线程阻塞了，我们就可以观察线程的状态，分享出一些原因。
注意：一个线程只能start一次，也就是说只有是NEW状态的线程才能start。
二、线程安全
线程安全：某个代码，不管它是单个线程执行，还是多个线程执行，都不会产生bug，这个情况就成为“线程安全”。
线程不安全：某个代码，它单个线程执行，不会产生bug，但是多个线程执行，就会产生bug，这个情况就成为 “线程不安全”，或者 “存在线程安全问题”。
举个线程不安全例子，现在，我们想计算一个变量的自增次数，它循环了100000次，用两个线程去计算，各自计算循环50000次的次数。
1、线程不安全样例
（1）根本原因，代码结构，直接原因的例子：
根本原因：线程的随机调度，抢占式执行
代码结构：不同线程修改同一数据
直接原因：多线程操作不是原子的
代码：
public class ThreadDemo4 { private static int count = 0; public static void main(String[] args) throws InterruptedException { Thread t1 = new Thread(() -> { for (int i = 1; i < 50000; i++) { count++; } }); Thread t2 = new Thread(() -> { for (int i = 50000; i <= 100000; i++) { count++; } }); t1.start(); t2.start(); t1.join(); t2.join(); System.out.println("count: " + count); } }
我们知道，从1到10_0000，肯定是自增了10_0000次，但是我们看看输出结果如何？
答案却不是10_0000，是50000多次，这是为何呢？原因就是多线程代码，它们是并发执行的。
这个count++是由cpu的三个指令构成的：
（1）load 从内存中读取数据到cpu的寄存器中。
（2）add 把寄存器中的值 + 1。
（3）save 把寄存器中的值写回到内存中。
因为上面两个线程是并发执行的，那么 t1 和 t2 线程的执行顺序就是无序的，他们可能同时读取数据，自增完再+1，下面用图示他们的一些可能性。
暂时就画这么多，因为线程并发的执行结果个数是无数的，并不是简单的排列组合就能穷举出来，因为并发的原因，可能 t1 线程它执行了两次，才执行一次 t2 线程，也可能更多，或者 t2 执行的次数更多，t1 线程只执行一次。就又要排列组合了，这些情况都是有可能的。
这时，t1 和 t2自增的时候，就可能拿的是同一个值，这两线程的其中一个自增后，没放回内存中，另一个线程就又拿了，这肯定是不符合我们预期的。
所以我们从上面的可能情况找，符合我们预期的效果就只有这两个了，如图：
那么这种情况也就是串行化执行，执行完 t1，再执行t2，或者两个顺序相反。
代码：
public class ThreadDemo4 { private static int count = 0; public static void main(String[] args) throws InterruptedException { Thread t1 = new Thread(() -> { for (int i = 1; i < 50000; i++) { count++; } }); Thread t2 = new Thread(() -> { try { t1.join(); } catch (InterruptedException e) { throw new RuntimeException(e); } for (int i = 50000; i <= 100000; i++) { count++; } }); t1.start(); t2.start(); t2.join(); System.out.println("count: " + count); } }
执行效果：
但这样就没必要使用多线程了，因为串行化，一个线程就能搞定了，使用多线程也没太大意义。
（2）内存可见性例子
一个线程读，一个线程写，也可能存在线程安全问题。
代码：
public class ThreadDemo3 { private static int flag = 1; public static void main(String[] args) { Thread t1 = new Thread(() -> { while (flag == 1) { //循环题里，啥也不写 } System.out.println("t1线程结束"); }); Thread t2 = new Thread(() -> { System.out.println("请输入flag的值"); Scanner scanner = new Scanner(System.in); flag = scanner.nextInt(); }); t1.start(); t2.start(); } }
执行预期是当我们输入不等于1的值，就打印 “t1线程结束”，但结果却不是，执行结果如下：
flag值是0吗？t1线程也在一直在循环下去，但t2线程是实实在在的改变flag的值，这是为什么呢？
这就涉及到了jvm内部的优化了，和内存可见性相关；
t1线程的flag==0这一操作有两个核心指令：
（1）load，读取内存flag的值到寄存器
（2）拿着寄存器中的值和0比较（条件跳转指令）
这里load的每次操作取到的值都是一样的，而当我们执行scanner操作，修改flag的值，load这一指令，已经执行上百亿次了，我们知道，从内存中取数据这一操作是非常耗时的，远远比条件跳转指令花时间，这时因为load开销太大，jvm就会产生怀疑，怀疑这个load操作是否有必要？从而给出优化，把从内存读数据load这一操作给优化掉了，比较激进，从而不会再从内存中拿数据，而是把load拿到的值放到寄存器中，从寄存器拿到数据，进行比较。这样可以大幅度的提高循环的执行速度。
补充：编译器 / jvm是非常厉害的，很多地方都涉及到优化，jvm可以智能的分析出你写的代码哪里不合适，对你的代码进行调整，在保证你代码原有的逻辑不变前提下，提高程序的执行效率。这个事情，单线程情况下还好，但是多线程就容易出现 误判。
而上面的例子，t2修改了内存，但是t1没看到内存变化，就称为内存可见性问题。而内存可见性问题，是高度依赖编译器优化的问题，啥时候会触发这一问题，不好说。
解决方案一：（t1 循环里加sleep）
代码：
public class ThreadDemo3 { private static int flag = 1; public static void main(String[] args) { Thread t1 = new Thread(() -> { while (flag == 1) { try { Thread.sleep(1); } catch (InterruptedException e) { throw new RuntimeException(e); } //循环题里，啥也不写 } System.out.println("t1线程结束"); }); Thread t2 = new Thread(() -> { System.out.println("请输入flag的值"); Scanner scanner = new Scanner(System.in); flag = scanner.nextInt(); }); t1.start(); t2.start(); } }
解释：t1 循环里面加不加sleep的区别是很大的，因为1秒中都可以让里面的循环执行上百亿次，这时，load的开销就非常大，代码的优化迫切程度就比较大；但是加了sleep后，load的开销就小了很多，代码的优化迫切程度就降低了。
解决方案二：（给flag变量加volatile修饰）
java提供volatile，其中一个核心作用，就是保证 “内存可见性”（另一功能：禁止指令重排序）可以使上述的优化被强制关闭，这样就可以确保循环每次都是从内存中拿数据了，但这样执行效率也会下降，但数据更为准确了，这在实际开发中，就要看需求，是期望数据更准一点，还是执行效率更快一点。
代码：
public class ThreadDemo3 { private volatile static int flag = 1; public static void main(String[] args) { Thread t1 = new Thread(() -> { while (flag == 1) { //循环题里，啥也不写 } System.out.println("t1线程结束"); }); Thread t2 = new Thread(() -> { System.out.println("请输入flag的值"); Scanner scanner = new Scanner(System.in); flag = scanner.nextInt(); }); t1.start(); t2.start(); } }
执行效果：
这样，内存可见性的问题就能解决了。
补充：我们上面对编译器优化是这样表述的：编译器发现，每次循环都要从内存中读取数据，内存开销都太大了，于是把读取内存这一操作优化成读取寄存器这一操作。
但是在JMM模型是这样描述的：编译器发现，每次循环都要从 “主内存” 中读取数据，就会把数据从 “主内存” 中复制下到 “工作内存” 中，后续每次读取都是在 “工作内容” 这读取。（这里的“工作内容代指cpu寄存器 + 缓存这一套东西”）
这里的 “主内存” 翻译成内存，“工作内存” 翻译成cpu寄存器 ；为啥我们的描述和JMM的描述不同呢？为了能说明白，通俗易懂。
JMM作为jav的规范文档，描述要严谨，java规范文档提供的这些词，本身也是抽象概念；如果描述成cpu寄存器或者缓存，会比较拗口，而且，不同的cpu，寄存器情况会不一样，缓存有几级也不一样，变数比较多，主要是为了严谨，也为了表述没那么绕，才引入“工作内容”这一词。而为啥要引入JMM（主内存，工作内容）呢？主要还是为了跨平台。
2、总结线程不安全的原因
（1）根本原因
操作系统上的线程是“抢占式执行”，随机调度的。
（2）代码结构
多个线程同时修改同一个变量。
（3）直接原因
多线程修改操作，本身不是原子的，比如count++，在cpu上有3个指令，可能修改还没保存，就被其他线程调度走了。
（4）内存可见性
一个线程读，一个线程写，也会导致线程安全的问题。
（5）指令重排序
编译器的一种优化，在保证代码逻辑不变的情况下，将一些代码的指令重新排序，从而提高代码的执行效率，但是有时候会因为重排序后，多线程编程就会出现线程安全问题。
3、针对上述原因给出的解决方案
对于原因1
我们无法给出解决方案，因为操作系统内部已经实现了“抢占式执行”，我们干预不了
对于原因2
分情况，有的时候，代码结构可以调整，有的时候调整不了。
对于原因3
把要修改的变量这操作，通过特殊手段，把这操作在系统里的多个指令打包成一个“整体”。例如加锁操作，而加锁的操作，就是把多个指令打包成一个原子的操作。
对于原因4
可以对代码进行调整，避免内存可见性的问题；也可以使用volatile进行修饰，强制把代码优化关了，这样数据就更准确了，但执行效率也就变慢了。
对于原因5
将某些可能会指令重排序的变量，加volatile修饰，强制取消指令重排序的优化。
注意：volatile可以解决内存可见性问题，也可以解决指令重排序的问题。
