Python之死锁
死锁分为两种情况,多进程/线程的死锁.或者是单线程的死锁.
1.首先看一下单线程的死锁,单线程的死锁一般是人为代码逻辑的错误,造成的死锁.比如在一段代码中,自己还没有释放锁,就重新想要去获取锁,就会造成死锁.
一个线程迭代请求同一个资源的时候造成的死锁
# encoding:utf-8
__author__ = 'Fioman'
__time__ = '2019/3/9 15:32'
import threading
import time
num = 0
class MyThread(threading.Thread):
mutex = threading.Lock()
def run(self):
global num
time.sleep(1)
if MyThread.mutex.acquire():
num = num + 1
msg = self.name + 'set num to ' + str(num)
print(msg)
MyThread.mutex.acquire()
MyThread.mutex.release()
MyThread.mutex.release()
def test():
for i in range(5):
t = MyThread()
t.start()
if __name__ == '__main__':
test()
在上面的例子中,因为对同一个资源的请求的锁还没有释放,就再次请求,就会出现死锁.解决的办法就是使用可重入的锁.
2.多进程或者线程的死锁
当多个进程或者线程在执行的过程中,因为资源争夺而造成的一种互相等待拿到对方所占有的锁的时候.就会造成死锁.
简单的描述下:就是这个意思.如果一个线程T1获得了A锁的使用权,还没有释放掉的时候,又想获取B锁的使用权.但是这个时候恰好有个线程T2正在占用B锁的使用权,而想获取A锁的使用权.
代码示例
# encoding:utf-8
__author__ = 'Fioman'
__time__ = '2019/3/9 16:33'
from threading import Thread, Lock
import time
class MyThread(Thread):
mutexA = Lock()
mutexB = Lock()
def run(self):
self.func1()
self.func2()
def func1(self):
MyThread.mutexA.acquire()
print('{}拿到了A锁'.format(self.name))
MyThread.mutexB.acquire()
print('{}拿到了B锁'.format(self.name))
MyThread.mutexB.release()
MyThread.mutexA.release()
def func2(self):
MyThread.mutexB.acquire()
print('{} 拿到了B锁'.format(self.name))
time.sleep(2)
MyThread.mutexA.acquire()
print('{} 拿到了A锁'.format(self.name))
MyThread.mutexA.release()
MyThread.mutexB.release()
if __name__ == '__main__':
for i in range(5):
t = MyThread()
t.start()
执行结果:
过程分析:
上面的程序运行的时候首先是启动线程1,线程1拿到了A锁,然后拿到了B锁.然后释放了B锁,释放了A锁.然后执行func2()拿到了B锁.然后休眠了2秒,这个时候的状态是线程1拿到B锁,休眠两秒之后准备去拿A锁.而这个时候线程二执行了func1,就拿到了A锁,想要去拿B锁,但是注意这个时候,线程1还占用着B锁,线程2就会等待,两秒过去了,线程1继续往下执行,想去拿A锁.但是这个时候的A锁已经被线程2拿着了,结果就是线程1拿着B,一直请求获取A.而线程2拿着A,一直请求获取B.就造成了死锁.
Python值递归锁,又叫可重入锁(RLock)
可重入锁是用来解决死锁的.其实就是一个锁对象可以被一个线程重复多次使用,而一般的锁的时候,我们在同一个进程或者线程如果要锁不同的地方,需要使用多个锁对象.可重入锁的原理就是,它在内部维护一个计数器,初始值是0.当遇到这个锁对象acquire()的时候计数就加1,当遇到release()的时候,计数就减一.它解决死锁的原理就是,当有另外线程要操作相同的资源的时候,会先去检查这个计数,只有当这个计数为0的时候,才会让其获取这段资源的使用权.否则就会等待.
可重入锁使用的时候注意的事项
获取几次,最后一定要释放几次.不然别的线程一直获取不到被锁住的资源.
# encoding:utf-8
__author__ = 'Fioman'
__time__ = '2019/3/9 16:52'
from threading import Thread, RLock
import time
rlock = RLock()
class MyThread(Thread):
def run(self):
self.f1()
self.f2()
def f1(self):
rlock.acquire()
print('{} 拿到了A锁'.format(self.name))
rlock.acquire()
print('{} 拿到了B锁'.format(self.name))
rlock.release()
rlock.release()
def f2(self):
rlock.acquire()
print('{} 拿到了A锁'.format(self.name))
time.sleep(2)
rlock.acquire()
print('{} 拿到了B锁'.format(self.name))
rlock.release()
rlock.release()
if __name__ == '__main__':
for i in range(5):
t = MyThread()
t.start()
互斥锁
概念:
互斥就是互相排斥的意思,在多个进程或线程对同一个资源请求的时候,如果每个进程或线程请求的时候都加锁,别的进程或线程就没法访问这里的资源,就会一直等待.直到占用该资源的那个进程或线程释放了该锁.所以互斥锁又叫排他锁,又叫同步锁.
在python中,多线程并发执行任务时,多个子线程有时候会争抢同一个主线程中的资源,导致程序报错,无法执行,这时,我们可以引入一个互斥锁的概念,使得一个资源在被一个子线程抓取到时候就不再被其他子线程抓取,直到第一个抓取到资源的子线程执行完程序,再释放出资源。
# encoding:utf-8
import time
__author__ = 'Fioman'
__time__ = '2019/3/9 17:09'
from threading import Thread, Lock
# 全局变量
num = 0
lock = Lock()
# 任务1:
def work1(number):
lock.acquire()
global num
for i in range(number):
time.sleep(0.1)
num += 1
print('此时的Num={}'.format(num))
lock.release()
# 任务2:
def work2(number):
# 上锁
lock.acquire()
global num
for i in range(number):
time.sleep(0.1)
num -= 1
print('此时的Num={}'.format(num))
# 释放资源
lock.release()
if __name__ == '__main__':
t1 = Thread(target=work1, args=(10,))
t2 = Thread(target=work2, args=(20,))
t1.start()
t2.start()
这样加锁以后,两个线程就变成串行执行了.就是一个线程执行完毕,之后另外一个线程才可以获取资源.
MySql的乐观锁和悲观锁
悲观锁
悲观锁(Pessimistic Lock),顾名思义就是很悲观.每次去操作数据的时候,都会认为别人会修改.所以为了防止别人修改,就在操作的时候上锁.这样别人来访问的时候就会阻塞在那里直到锁被是释放.传统的关系型数据库里面就用到了很多这种锁机制,比如行锁,表锁,读锁,写锁等,都是在操作之前先上锁.
使用场景:
商品goods表中有一个字段status,status为1代表商品未被下单,status为2代表商品已经被下单,那么我们对某个商品下单的时候必须确保该商品status为1.假设商品id为1.
# encoding:utf-8
__author__ = 'Fioman'
__time__ = '2019/3/10 13:49'
# 如果不使用锁,那么操作方法如下:
# 1.查询出商品信息
select status from t_goods where id = 1;
# 2.根据商品信息生成订单
insert into t_orders(id,goods_d) values(null,1);
# 3.修改商品status为2
update t_goods set status=2;
上面这种场景在高并发访问的情况下很可能会出现问题.
前面已经提到,只有上status为1的时候,才能对该商品下单,上面的第一步操作中
查询出来的上面品status为1,但是当我们执行第二步的时候,很有可能有的人先一步
执行了2和3,此时订单已经被下过了,然后我们又下了一次.很有可能就出现一个订单被
下单了两次的情况.
# 解决这种问题的方法,我们使用悲观锁来实现.
在上面的场景中,商品信息从查询出来到修改,中间有一个处理订单的过程.
使用悲观锁的原理就是,当我们查询goods的信息时,就把当前的数据锁住,
直到我们修改完毕后再解锁.那么在这个过程中,因为goods被锁定了,就不会
出现有第三者来对其进行修改了.
注意:如果要使用悲观锁,我们必须将mysql数据库的自动提交功能关闭.
因为mysql默认使用autocommit模式,也就是说,当你执行一个更新操作后,
MySql会立即将结果进行提交
我们可以使用命令设置MySQL为非autocommit的模式:
set autocommit=0;
设置完autocommit后,我们就可以执行我们的正常业务了.具体如下:
# 0.事务开始
begin;/begin work;/start trasaction;(三者选一即可)
# 1.查询出商品信息
select status from t_goods where id=1 for update;
# 2.根据商品信息生成订单
insert into t_orders (id ,goods_id) values (null,1);
# 3.修改商品status为2
update t_goods set status=2;
# 4.提交事务
commit;/ commint work;
上面的第一步我们执行了一次查询操作:
select status from t_goods from t_good where id=1 for update;
与普通查询不一样的是,我们使用了select... for update的方式,这样就通过
数据库实现了悲观锁.此时t_goods表中,id为1的那条数据就被我们锁定了,其他的事务必须等
本次事务提交之后才能执行.这样我们可以保证当前的数据不会被其他事务修改.
备注:
使用select for update会把数据给锁住,不过我们需要注意一些锁的级别,MySql InnoDB
默认行级锁.行级锁都是基于索引的,如果一条SQL语句用不到索引是不会使用行级锁的.
会使用表级锁将整张表锁住,这点需要注意.
优点和不足
悲观锁的策略是先取锁再访问,保证了数据的安全性.但是效率方面,处理加锁机制会让数据库产生额外的开销.
还有即使增加了产生死锁的可能.
所以一般只有在写的操作冲突多的时候才使用悲观锁,而读的操作不需要加锁.
乐观锁
乐观锁(Optimistic Lock),顾名思义,就是很乐观,每次去拿数据的时候都认为比人不会修改,所以不会上锁.
但是在更新数据的时候,会判断一下在更新数据的这段时间内,数据有没有被修改.如果被修改了,如果被修改了
就取消这次操作,如果没有被修改,则使得这次操作生效.一般使用版本号或者时间戳的方式来实现.
数据库版本:
我数据库增加一个字段version.当我们操作数据的时候,将版本号一同取出来,当我们更新数据,
在提交更新的时候,会再去数据查询下当前的版本号,跟我们之前取出来的版本号,是否一致.如果
一致,就使得这次更新生效.并且在每次更新数据的时候,都使得版本号加1.
使用版本号实现乐观锁
使用版本号时,可以再数据初始化时指定一个版本号,每次对数据的更新操作都对版本号执行+1操作.
并判断一下当前的版本号是不是该数据的最新的版本号.
1. 查询出商品信息
select (status,status,version)from t_goods where id = #{id}
2.根据商品信息生成订单
3.修改商品status为2
update t_goods set status=2,version=version+1
where id=#{id} and version=#{version}
优点和不足
乐观并发控制相信事务之间的数据竞争的概率是比较小的,会先进行操作.
再提交的时候再进行验证这次提交是否可行,因此不会有任何的死锁和锁.但是这样做
还是有问题的,例如如果某两个事务对同一行的数据同时进行了修改,经过修改之后,
同时写进了数据库,这时就会出现问题.所以乐观锁,一般用在读数据比较多的地方.
而对于写数据比较多的地方,我们最好使用悲观锁来解决.
行级锁和死锁
在MySql中,行级锁并不是直接锁记录,而是锁索引.索引分为主键索引和非主键索引两种.
如果一条sql语句操作了主键索引,MySql就会锁住这条主键索引.如果一条语句操作了
非主键索引,MySQL会先锁定该非主键索引,再锁定相关的主键索引.在UPDATE,DELETE操作时,
MYSQL不仅锁定WHERE条件扫描过的所有索引记录,而且会锁定相邻的键值,即所谓的
next-key locking
当两个事务同时执行,一个锁住了主键索引,在等待其他相关索引.另一个锁住了非主键索引,在等待主键索引.
就发生了死锁.
放生死锁以后,一般InnoDB可以检测到,会将一个事务进行回滚,释放掉占用的锁.另一个事务获取到锁完成事务.