2、采用按序加锁法.预先规定一个封锁顺序,所有的事务都必须按这个顺序对数据执行封锁。
3、不采取任何措施来预防死锁的发生,而是周期性地检查系统中是否有死锁.如果发现死锁就设法解除。
死锁主要表现以下几种情况:表现一:
一个用户A 访问表A(锁住了表A),然后又访问表B
另一个用户B 访问表B(锁住了表B),然后企图访问表A
这时用户A由于用户B已经锁住表B,它必须等待用户B释放表B,才能继续,好了他老人家就只好老老实实在这等了
同样用户B要等用户A释放表A才能继续这就死锁了
解决方法:
这种死锁是由于你的程序的BUG产生的,除了调整你的程序的逻辑别无他法
仔细分析你程序的逻辑,
1:尽量避免同时锁定两个资源
2: 必须同时锁定两个资源时,要保证在任何时刻都应该按照相同的顺序来锁定资源.
表现二:
用户A读一条纪录,然后修改该条纪录
这是用户B修改该条纪录
这里用户A的事务里锁的性质由共享锁企图上升到独占锁(for update),而用户B里的独占锁由于A有共享锁存在所以必须等A释
放掉共享锁,而A由于B的独占锁而无法上升的独占锁也就不可能释放共享锁,于是出现了死锁。
这种死锁比较隐蔽,但其实在稍大点的项目中经常发生。
解决方法:
让用户A的事务(即先读后写类型的 *** 作),在select 时就是用Update lock
语法如下:
select * from table1 with(updlock) where ....
如果真的table被锁住了,可以通过下面的方法来解锁:
Sql server企业管理器->对应的数据库->管理->当前活动->锁/进程ID
将对应的被锁住的进程关闭。
还有一种方法,就是在你不知道究竟是哪张表被锁,由何种原因被锁,可以重新启动数据库来解决,但不保证下次又被锁住,因为还没有找到问题的根本原因。
要避免锁表,在 *** 作数据库最好不要用独占方式。
1、避免给一个锁嵌套上锁,在持有一个锁的时候,不要再给这个锁上锁。如果使用多个锁,使用std::lock。
2、在持有锁时,不要调用别人提供的函数,因为你不清楚别人的代码怎么实现的,不知道它是不是在使用锁。
3、给多个锁上锁时,固定顺序。如果在给多个所上锁,并且无法使用std::lock,最好的做法就是在每一个线程中,都按照同样的顺序。
4、分层次来使用锁,把程序分成几个层次。区分每个层次中使用的锁,当一个线程已经持有更低层次的锁时,不允许使用高层次的锁。可以在程序运行时给不同的锁加上层次号,记录每个线程持有的锁。
扩展资料:
解决方法
在系统中已经出现死锁后,应该及时检测到死锁的发生,并采取适当的措施来解除死锁。
死锁预防。
这是一种较简单和直观的事先预防的方法。方法是通过设置某些限制条件,去破坏产生死锁的四个必要条件中的一个或者几个,来预防发生死锁。预防死锁是一种较易实现的方法,已被广泛使用。但是由于所施加的限制条件往往太严格,可能会导致系统资源利用率和系统吞吐量降低。
死锁避免。
系统对进程发出的每一个系统能够满足的资源申请进行动态检查,并根据检查结果决定是否分配资源;如果分配后系统可能发生死锁,则不予分配,否则予以分配。这是一种保证系统不进入死锁状态的动态策略。
死锁检测和解除。
先检测:这种方法并不须事先采取任何限制性措施,也不必检查系统是否已经进入不安全区,此方法允许系统在运行过程中发生死锁。但可通过系统所设置的检测机构,及时地检测出死锁的发生,并精确地确定与死锁有关的进程和资源。检测方法包括定时检测、效率低时检测、进程等待时检测等。
然后解除死锁:采取适当措施,从系统中将已发生的死锁清除掉。
这是与检测死锁相配套的一种措施。当检测到系统中已发生死锁时,须将进程从死锁状态中解脱出来。常用的实施方法是撤销或挂起一些进程,以便回收一些资源,再将这些资源分配给已处于阻塞状态的进程,使之转为就绪状态,以继续运行。死锁的检测和解除措施,有可能使系统获得较好的资源利用率和吞吐量,但在实现上难度也最大。
参考资料:死锁百度百科
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)