1.进程的状态

public class Test {public static void main(String[] args) throws InterruptedException {Thread t=new Thread(()->{});System.out.println(t.getState());//线程已经创建，但是没有开始执行，这个时候的状态就是new状态t.start();t.join();//TERMINATED就是线程结束之后的这个线程的状态:terminatedSystem.out.println(t.getState());}}

下面的这个就是在我们的t线程里面设计一个死循环，这个时候我们就可以使用getstate获取到这个时候的状态就是我们的runnable状态的；

下面的这个是对于timed-waiting状态的演示：

2.线程的安全引入

线程的安全问题：主要就是这个线程调度的随机性；

下面的这个里面，我们是对于这个全局的静态变量是count=0,我们在这个主方法里面对于这个count分别加上50000次，这个时候我们正常情况下结果应该是100000，但是这个打印结果不是100000，主要就是因为这个调度器的执行问题导致的这个结果不是100000；

实际上，这个count进行++的时候，需要经过三个步骤，分别是

load:把内存里面的数据进行读取到CPU寄存器里面去；

add:把这个寄存器里面的数据count++;

save:把这个寄存器里面的计算之后的数据放到这个内存里面去；

为什么计算之后的这个结果不是100000呢，下面我们画一下这个计算的过程：

如果是下面的这个情况，我们的两个线程的三步骤都是连续的，这个时候我们的count就会被加上去，这个时候就是2；

但是如果下面的这个情况，就是两个线程之间的这个三步操作就会失效，只有一个会发挥作用，因为其中的一个过程被中断了：

3.线程安全的问题产生原因

1.操作系统里面对于线程的调度是随机的（抢占式执行）；

​ 我们想要解决问题肯定不可以从这个入手，因为这个是取决于我们的操作系统，我们很难对于这个抢占 式执行的现状进行控制；

2.两个线程，针对于一个变量进行修改；

​ 上面的这个就是属于这个情况，两个线程都是针对于这个count进行操作，因此这个时候因为这个调度执 行的步骤可能会被切断，因此这个时候就会出现问题；

3.修改操作不是原子的；

​ 什么是原子：上面的这个count++就不是原子的，原子的简单的就可以理解为这个操作的步骤是一步到位

​ 还是需要分为多次进行执行，上面的这个load,add,save需要分为三个步骤进行执行，因此这个就不是原 子的；

​ 假设我们的这个步骤一步就可以完成，这个时候我们就把这个操作叫做原子的；

4.内存可见性问题；

5指令重排序问题；（4,5）我们暂时没有遇到，因此这个地方不进行过多的介绍；

4.synchronized关键字的引入

4.1修饰代码块

我们的这个synchronized实际上就是对于这个操作进行加锁的操作，只有我们的一个线程的三个步骤全部执行完毕之后，我们的另外一个线程才会被执行，相当于我们的t1对于这个全局的变量++的时候，这个就是出于上锁的状态，其他的线程无法进行操作，只有当我们的这个线程执行完毕之后，这个锁被释放掉，也就是开锁，这个时候我们的其他的线程才可以继续执行；

这样的操作保证了这个不同的线程之间的这个操作的独立性，就不会出现上面介绍的一个线程的三个步骤被另外一个线程打断，出现两个线程的操作交叉执行的问题；就是这个load,add,save就是各走各的，而且三个过程是连续的，不会被中断；

除了上面的这个synchronized修饰代码块之外，我们的这个synchronized还是可以修饰我们的静态方法和我们的实例方法的：

4.2修饰实例方法

所谓的这个实例方法，其实就是为了和我们的静态方法进行区分，就是一个类里面的普通的成员方法，下面的这个就是我们的synchronized修饰我们的实例方法，下面的两个本质是等效的，因为这个synchronized修饰我们的实例方法本质上就是对于这个this锁对象进行操作，这个时候的锁对象就是我们的this；

因此这样来讲，上面的操作和我们的下面的这个修饰方法就是一样的，只不过我们的这个下面的写法里面，把这个锁对象隐藏了起来；

4.3修饰静态方法

下面的两个写法就是一样的，就是我们的synchronized关键字修饰我们的静态成员方法，相当于这个代码块里面的这个参数就是我们的类对象；

我们的代码里面定义了一个类，那么这个里面就一定会有一个类对象，而且一个类只会有一个类对象，不会有多个的；

public class Test {public static void main(String[] args) {synchronized public static void increase(){}public static increase2(){synchronized (counter.class){}}}
}

4.4对象头介绍

synchrinozed修饰的这个锁是存在于我们的这个对象头里面的，那么什么是对象头：

对象头就是我们进行这个对象的创建的时候，一个对象会有自己的内存空间，在这个内存空间里面，除了我们自己对于这个对象定义的属性，这个对象还会有些默认的属性，这个默认的属性就是在我们的对象头里面的；

在对象头里面，就有属性是存放说明我们的这个对象是不是加上了锁的；

4.5死锁-可重入的特性

什么是可重入 ，就是对于一个对象，我们连续加锁，这个时候不会出现死锁的情况；

我们使用下面的这个案例对于死锁进行说明:

死锁就是像下面的这个情况一样，我们连续对哦与一个锁对象多次加锁，这个时候就会出现死锁，具体的讲就是线程被卡死了；

synchronized(locker){synchronized(locker){.......}
}

为什么会出现下面的这个死锁的情况，就是我们的第一次加锁的时候，我们的第二次操作正常情况下是进不去的，需要第一次的这个吧这个锁打开之后我们才可以第二次进入，但是下面的这个情况下我们的这个锁想要打开，只有等到这个操作执行完，就是这个代码块执行完，也就是执行到我们下面的这个示例代码的第二个}位置才可以，但是想要执行到这个第二个}位置，必须要执行这个第二次的加锁的操作，这个就是矛盾的地方；

因此这个时候想要加锁，但是这个执行又无法结束，因此这个时候就会出现线程卡死的情况，也就是我们说的死锁现象，为了处理这个问题，synchronized关键字引入了这个可重入的特性，就是对于这个相同的锁对象，我们可以重入，就是反复的入，也就是反复地加锁，这个是可以被允许的；

当然，这个死锁的现象是针对于这个相同的锁对象多次加锁，这个时候才可能会出现死锁的情况，如果每一次加锁针对的锁对象不是一样的，这个时候是不会出现我们的死锁现象的；

synchronized(locker){//下面的这个是针对于一个新的锁对象进行加锁，这个时候肯定不会出现死锁的情况，无论是不是可重入的synchronized(locker2){.......}
}

那么，在这个可重入的特性下，我们的这个锁什么时候打开呢，正确答案是，直到所有的这个锁全部加上之后，直到我们的这个最外层大括号的时候，这个锁才会被打开；

具体到下面的这个情况，就是执行到最后一个}的时候，这个锁才会被打开，这个过程里面，我们会不断的进行计数，就是这个锁一共加上了几层,即n++，打开的时候，也会不断的对于这个n–直到这个走到最后一个}的时候，这个时候的n=0,也就是我们释放锁的时候；

synchronized(locker){synchronized(locker){synchronized(locker){synchronized(locker){synchronized(locker){..........}}}}
}

5.关于死锁的分析总结

5.1死锁的分析

1.一个对象，被连续两次上锁，这个时候如果是不可重入锁，就会发生死锁的现象；

2.两个对象，两把锁，这个时候无论是不是可重入的，都会发生这个死锁现象；

这个经典案例就是我们的钥匙落在了车里，车钥匙落在了家里，这个时候就会出现思索的现象；

这个时候家和车就是两个对象，我们的车钥匙和家钥匙就是锁，这个时候出现的情况就是我们的死锁的现象；

3.N个对象，M把锁，这个时候就是上面的两个对象两把锁的扩展，这个时候更加容易出现死锁的现象；

最经典的N歌对象，M把锁的问题就是我们的哲学家就餐问题：

这个时候我们是使用5个滑稽作为案例的，没有画出来很多，我们的滑稽在就餐的时候，每一个人都是拿走的自己的最近的一个筷子，这个时候，每一个人只有一个，谁都无法就餐，所有的人就是阻塞的状态，这个时候就会出现死锁的现象；（下面我们会介绍这个解决的方案）；

5.2死锁成因的必要条件

死锁的成因，需要满足下面的这四个条件，并且是同时满足的：

1.互斥使用（死锁的基本特性）：当一个线程有一把锁之后，另外一个线程想要使用这个锁，需要进行阻塞等待；

2.不可抢占（死锁的基本特性）：当一个锁被线程1拿到之后，线程2只能等待这个线程1主动地进行释放，否则只能处于等待的状态；

3.请求保持（代码结构）：一个线程尝试获取多把锁，先拿到第一把锁之后，尝试获取第二把锁，获取这个锁的时候，第一把锁不会被释放；

4.循环等待/环路等待：等待之间的依赖关系，形成了换；

例如一个例子：钥匙锁在了车里，车钥匙锁在了家里；这个就是一个循环的环路等待，这个结果就是一个死循环，也是死锁的一个成因；

5.3死锁的解决方案

解决死锁问题的核心就是要破坏上面的必要条件，但是这个里面的第一和第二个必要条件就是我们的锁的特性，因此这个不需要进行考虑，我们主要针对于3,4两个必要条件进行解决；

针对于3这个现象，我们需要进行这个代码结构的调整，不要把两个加锁的代码放到一个代码块里面去；

针对于4这个现象，我们需要进行编号操作，可以有效的解决这个问题：

还是使用这个哲学家的就餐问题，我们进行编号之后，让每一个滑稽取出来这个最小的编号的筷子（自己面前的两个筷子里面的最小的），这样的话，我们的问题就解决了；

我们可以分析一下这个就餐的过程，我们的拿筷子的情况如图所示，每一个人拿的都是自己的这个面前的两个里面的最小的编号，我们的最后一个滑稽取筷子的时候，1和5相比，肯定是1小，这个时候他就不可以取走这个5编号的筷子，这个时候的1已经是被和他相邻的这个滑稽取走了，因此这个时候，只能等待人家用完；

因此这个时候我们的左上角的这个滑稽就可以拿到这个5开始就餐，放下筷子之后，我们的左下角的这个滑稽拿到这个4号筷子吃饭，以此类推，直到我们的右上角的这个滑稽放下筷子，这个时候我们的最上面的这个滑稽就可以吃饭了，这个线程的死锁问题就被解决了；

定是1小，这个时候他就不可以取走这个5编号的筷子，这个时候的1已经是被和他相邻的这个滑稽取走了，因此这个时候，只能等待人家用完；

因此这个时候我们的左上角的这个滑稽就可以拿到这个5开始就餐，放下筷子之后，我们的左下角的这个滑稽拿到这个4号筷子吃饭，以此类推，直到我们的右上角的这个滑稽放下筷子，这个时候我们的最上面的这个滑稽就可以吃饭了，这个线程的死锁问题就被解决了；