天津建设合同备案网站,c 做注册网站,企业网站模板公司,识图文章目录 1.进程的状态2.线程的安全引入3.线程安全的问题产生原因4.synchronized关键字的引入4.1修饰代码块4.2修饰实例方法4.3修饰静态方法4.4对象头介绍4.5死锁-可重入的特性 5.关于死锁的分析总结5.1死锁的分析5.2死锁成因的必要条件5.3死锁的解决方案 1.进程的状态
public… 文章目录 1.进程的状态2.线程的安全引入3.线程安全的问题产生原因4.synchronized关键字的引入4.1修饰代码块4.2修饰实例方法4.3修饰静态方法4.4对象头介绍4.5死锁-可重入的特性 5.关于死锁的分析总结5.1死锁的分析5.2死锁成因的必要条件5.3死锁的解决方案 1.进程的状态
public class Test {public static void main(String[] args) throws InterruptedException {Thread tnew Thread(()-{});System.out.println(t.getState());//线程已经创建但是没有开始执行这个时候的状态就是new状态t.start();t.join();//TERMINATED就是线程结束之后的这个线程的状态:terminatedSystem.out.println(t.getState());}}下面的这个就是在我们的t线程里面设计一个死循环这个时候我们就可以使用getstate获取到这个时候的状态就是我们的runnable状态的 下面的这个是对于timed-waiting状态的演示 2.线程的安全引入
线程的安全问题主要就是这个线程调度的随机性
下面的这个里面我们是对于这个全局的静态变量是count0,我们在这个主方法里面对于这个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–直到这个走到最后一个}的时候这个时候的n0,也就是我们释放锁的时候
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号筷子吃饭以此类推直到我们的右上角的这个滑稽放下筷子这个时候我们的最上面的这个滑稽就可以吃饭了这个线程的死锁问题就被解决了
