2.public void foo() {
3.boolean flag = false
4.if(flag) {
5.//this could happen
6.}
7.}
8.} 一个优化的编译器可能会判断出if部分的语句永远不会被执行,就根本不会编译这部分的代码。如果这个类被多线程访问, flag被前面某个线程设置之后,在它被if语句测试之前,可以被其他线程重新设置。用volatile关键字来声明变量,就可以告诉编译器在编译的时候,不需要通过预测变量值来优化这部分的代码。 无法访问的Java线程死锁有时候虽然获取对象锁没有问题,线程依然有可能进入阻塞状态。在 Java 编程中IO就是这类问题最好的例子。当线程因为对象内的IO调用而阻塞时,此对象应当仍能被其他线程访问。该对象通常有责任取消这个阻塞的IO操作。造成阻塞调用的线程常常会令同步任务失败。如果该对象的其他方法也是同步的,当线程被阻塞时,此对象也就相当于被冷冻住了。 其他的线程由于不能获得对象的Java线程死锁,就不能给此对象发消息(例如,取消 IO 操作)。必须确保不在同步代码中包含那些阻塞调用,或确认在一个用同步阻塞代码的对象中存在非同步方法。尽管这种方法需要花费一些注意力来保证结果代码安全运行,但它允许在拥有对象的线程发生阻塞后,该对象仍能够响应其他线程。 编辑推荐: 1. Java多线程优化之偏向锁原理分析 2. Java多线程实现异步调用的方法 3. 使用Java多线程机制实现下载的方法介绍
对资源采用同步,还有银行家算法银行家算法是一种最有代表性的避免死锁的算法。在避免死锁方法中允许进程动态地申请资源,但系 银行家算法
统在进行资源分配之前,应先计算此次分配资源的安全性,若分配不会导致系统进入不安全状态,则分配,否则等待。为实现银行家算法,系统必须设置若干数据结构。 要解释银行家算法,必须先解释操作系统安全状态和不安全状态。 安全序列是指一个进程序列{P1,…,Pn}是安全的,如果对于每一个进程Pi(1≤i≤n),它以后尚需要的资源量不超过系统当前剩余资源量与所有进程Pj (j <i )当前占有资源量之和。
安全状态
如果存在一个由系统中所有进程构成的安全序列P1,…,Pn,则系统处于安全状态。安全状态一定是没有死锁发生。
不安全状态
不存在一个安全序列。不安全状态不一定导致死锁。
算法的实现
初始化
由用户输入数据,分别对可利用资源向量矩阵AVAILABLE、最大需求矩阵MAX、分配矩阵ALLOCATION、需求矩阵NEED赋值。
银行家算法
在避免死锁的方法中,所施加的限制条件较弱,有可能获得令人满意的系统性能。在该方法中把系统的状态分为安全状态和不安全状态,只要能使系统始终都处于安全状态,便可以避免发生死锁。 银行家算法的基本思想是分配资源之前,判断系统是否是安全的若是,才分配。它是最具有代表性的避免死锁的算法。 设进程cusneed提出请求REQUEST [i],则银行家算法按如下规则进行判断。 (1)如果REQUEST [cusneed] [i]<= NEED[cusneed][i],则转(2);否则,出错。 (2)如果REQUEST [cusneed] [i]<= AVAILABLE[cusneed][i],则转(3);否则,出错。 (3)系统试探分配资源,修改相关数据: AVAILABLE[i]-=REQUEST[cusneed][i]ALLOCATION[cusneed][i]+=REQUEST[cusneed][i]NEED[cusneed][i]-=REQUEST[cusneed][i](4)系统执行安全性检查,如安全,则分配成立;否则试探险性分配作废,系统恢复原状,进程等待。
安全性检查算法
(1)设置两个工作向量Work=AVAILABLEFINISH (2)从进程集合中找到一个满足下述条件的进程, FINISH==falseNEED<=Work如找到,执行(3);否则,执行(4) (3)设进程获得资源,可顺利执行,直至完成,从而释放资源。 Work+=ALLOCATIONFinish=trueGOTO 2 (4)如所有的进程Finish= true,则表示安全;否则系统不安全。
什么是死锁,如何避免死锁?线程A需要资源X,而线程B需要资源Y,而双方都掌握有对方所要的资源,这种情况称为死锁(deadlock),或死亡拥抱(thedeadlyembrace)。
在并发程序设计中,甘肃电脑培训http://www.kmbdqn.cn/建议死锁(deadlock)是一种十分常见的逻辑错误。
通过采用正确的编程方式,死锁的发生不难避免。
死锁的四个必要条件在计算机专业的教材中,通常都会介绍死锁的四个必要条件。
这四个条件缺一不可,或者说只要破坏了其中任何一个条件,死锁就不可能发生。
我们来复习一下,这四个条件是:互斥(Mutualexclusion):存在这样一种资源,它在某个时刻只能被分配给一个执行绪(也称为线程)使用;持有(Holdandwait):当请求的资源已被占用从而导致执行绪阻塞时,资源占用者不但无需释放该资源,而且还可以继续请求更多资源;不可剥夺(Nopreemption):执行绪获得到的互斥资源不可被强行剥夺,换句话说,只有资源占用者自己才能释放资源;环形等待(Circularwait):若干执行绪以不同的次序获取互斥资源,从而形成环形等待的局面,想象在由多个执行绪组成的环形链中,每个执行绪都在等待下一个执行绪释放它持有的资源。
解除死锁的必要条件不难看出,在死锁的四个必要条件中,第二、三和四项条件比较容易消除。
通过引入事务机制,往往可以消除第二、三两项条件,方法是将所有上锁操作均作为事务对待,一旦开始上锁,即确保全部操作均可回退,同时通过锁管理器检测死锁,并剥夺资源(回退事务)。
这种做法有时会造成较大开销,而且也需要对上锁模式进行较多改动。
消除第四项条件是比较容易且代价较低的办法。
具体来说这种方法约定:上锁的顺序必须一致。
具体来说,我们人为地给锁指定一种类似“水位”的方向性属性。
无论已持有任何锁,该执行绪所有的上锁操作,必须按照一致的先后顺序从低到高(或从高到低)进行,且在一个系统中,只允许使用一种先后次序。
请注意,放锁的顺序并不会导致死锁。
也就是说,尽管按照锁A,锁B,放A,放B这样的顺序来进行锁操作看上去有些怪异,但是只要大家都按先A后B的顺序上锁,便不会导致死锁。
解决方法:1使用事务时,尽量缩短事务的逻辑处理过程,及早提交或回滚事务(细化处理逻辑,执行一段逻辑后便回滚或者提交,然后再执行其它逻辑,直到事物执行完毕提交);2设置死锁超时参数为合理范围,如:3分钟-10分种;超过时间,自动放弃本次操作,避免进程悬挂; 3优化程序,检查并避免死锁现象出现; 4对所有的脚本和SP都要仔细测试,在正是版本之前。
5所有的SP都要有错误处理(通过@error) 6一般不要修改SQLSERVER事务的默认级别。
不推荐强行加锁另外参考的解决方法:按同一顺序访问对象如果所有并发事务按同一顺序访问对象,则发生死锁的可能性会降低。
例如,如果两个并发事务获得Supplier表上的锁,然后获得Part表上的锁,则在其中一个事务完成之前,另一个事务被阻塞在Supplier表上。
第一个事务提交或回滚后,第二个事务继续进行。
不发生死锁。
将存储过程用于所有的数据修改可以标准化访问对象的顺序。