python互斥锁_Python互斥锁（Lock）：解决多线程安全问题

多线程的优势在于并发性，即可以同时运行多个任务。但是当线程需要使用共享数据时，也可能会由于数据不同步产生“错误情况”，这是由系统的线程调度具有一定的随机性造成的。

互斥锁的作用就是解决数据不同步问题。关于互斥锁，有一个经典的“银行取钱”问题。银行取钱的基本流程可以分为如下几个步骤：

用户输入账户、密码，系统判断用户的账户、密码是否匹配。

用户输入取款金额。

系统判断账户余额是否大于取款金额。

如果余额大于取款金额，则取款成功；如果余额小于取款金额，则取款失败。

乍一看上去，这确实就是日常生活中的取款流程，这个流程没有任何问题。但一旦将这个流程放在多线程并发的场景下，就有可能出现问题。注意，此处说的是有可能，并不是一定。也许你的程序运行了一百万次都没有出现问题，但没有出现问题并不等于没有问题！

按照上面的流程编写取款程序，并使用两个线程分别模拟两个人使用同一个账户做并发取钱操作。此处忽略检查账户和密码的操作，仅仅模拟后面三步操作。下面先定义一个账户类，该账户类封装了账户编号和余额两个成员变量。

classAccount:#定义构造器

def __init__(self, account_no, balance):#封装账户编号、账户余额的两个成员变量

self.account_no =account_no

self.balance= balance

接下来程序会定义一个模拟取钱的函数，该函数根据执行账户、取钱数量进行取钱操作，取钱的逻辑是当账户余额不足时无法提取现金，当余额足够时系统吐出钞票，余额减少。

程序的主程序非常简单，仅仅是创建一个账户，并启动两个线程从该账户中取钱。程序如下：

importthreadingimporttimeimportAccount#定义一个函数来模拟取钱操作

defdraw(account, draw_amount):#账户余额大于取钱数目

if account.balance >=draw_amount:#吐出钞票

print(threading.current_thread().name\+ "取钱成功！吐出钞票:" +str(draw_amount))#time.sleep(0.001)

#修改余额

account.balance -=draw_amountprint("\t余额为:" +str(account.balance))else:print(threading.current_thread().name\+ "取钱失败！余额不足！")#创建一个账户

acct = Account.Account("1234567" , 1000)#模拟两个线程对同一个账户取钱

threading.Thread(name='甲', target=draw , args=(acct , 800)).start()

threading.Thread(name='乙', target=draw , args=(acct , 800)).start()

先不要管程序中第 12 行被注释掉的代码，上面程序是一个非常简单的取钱逻辑，这个取钱逻辑与实际的取钱操作也很相似。

多次运行上面程序，很有可能都会看到如图 1 所示的错误结果。

甲取钱成功！吐出钞票:800

乙取钱成功！吐出钞票:800

余额为: 200

余额为: -600

所示的运行结果并不是银行所期望的结果(不过有可能看到正确的运行结果)，这正是多线程编程突然出现的“偶然” 错误因为线程调度的不确定性。

假设系统线程调度器在注释代码处暂停，让另一个线程执行(为了强制暂停，只要取消程序中注释代码前的注释即可)。取消注释后，再次运行程序，将总可以看到如图 1 所示的错误结果。

问题出现了，账户余额只有 1000 元时取出了 1600 元，而且账户余额出现了负值，远不是银行所期望的结果。虽然上面程序是人为地使用 time.sleep(0.001) 来强制线程调度切换，但这种切换也是完全可能发生的(100000 次操作只要有 1 次出现了错误，那就是由编程错误引起的)。

Python互斥锁同步线程

之所以出现如图 1 所示的错误结果，是因为 run() 方法的方法体不具有线程安全性，程序中有两个并发线程在修改 Account 对象，而且系统恰好在注释代码处执行线程切换，切换到另一个修改 Account 对象的线程，所以就出现了问题。

为了解决这个问题，Python 的 threading 模块引入了互斥锁(Lock)。threading 模块提供了 Lock 和 RLock 两个类，它们都提供了如下两个方法来加互斥锁和释放互斥锁：

acquire(blocking=True, timeout=-1)：请求对 Lock 或 RLock 加锁，其中 timeout 参数指定加锁多少秒。

release()：释放锁。

Lock 和 RLock 的区别如下：

threading.Lock：它是一个基本的锁对象，每次只能锁定一次，其余的锁请求，需等待锁释放后才能获取。

threading.RLock：它代表可重入锁(Reentrant Lock)。对于可重入锁，在同一个线程中可以对它进行多次锁定，也可以多次释放。如果使用 RLock，那么 acquire() 和 release() 方法必须成对出现。如果调用了 n 次 acquire() 加锁，则必须调用 n 次 release() 才能释放锁。

由此可见，RLock 锁具有可重入性。也就是说，同一个线程可以对已被加锁的 RLock 锁再次加锁，RLock 对象会维持一个计数器来追踪 acquire() 方法的嵌套调用，线程在每次调用 acquire() 加锁后，都必须显式调用 release() 方法来释放锁。所以，一段被锁保护的方法可以调用另一个被相同锁保护的方法。

Lock 是控制多个线程对共享资源进行访问的工具。通常，锁提供了对共享资源的独占访问，每次只能有一个线程对 Lock 对象加锁，线程在开始访问共享资源之前应先请求获得 Lock 对象。当对共享资源访问完成后，程序释放对 Lock 对象的锁定。

在实现线程安全的控制中，比较常用的是 RLock。通常使用 RLock 的代码格式如下：

classX:#定义需要保证线程安全的方法

defm () :#加锁

self.lock.acquire()try:#需要保证线程安全的代码

＃...方法体#使用finally 块来保证释放锁

finally:#修改完成，释放锁

self.lock.release()

使用 RLock 对象来控制线程安全，当加锁和释放锁出现在不同的作用范围内时，通常建议使用 finally 块来确保在必要时释放锁。

通过使用 Lock 对象可以非常方便地实现线程安全的类，线程安全的类具有如下特征：

该类的对象可以被多个线程安全地访问。

每个线程在调用该对象的任意方法之后，都将得到正确的结果。

每个线程在调用该对象的任意方法之后，该对象都依然保持合理的状态。

总的来说，不可变类总是线程安全的，因为它的对象状态不可改变；但可变对象需要额外的方法来保证其线程安全。例如，上面的 Account 就是一个可变类，它的 self.account_no和self._balance(为了更好地封装，将 balance 改名为 _balance)两个成员变量都可以被改变，当两个钱程同时修改 Account 对象的 self._balance 成员变量的值时，程序就出现了异常。下面将 Account 类对 self.balance 的访问设置成线程安全的，那么只需对修改 self.balance 的方法增加线程安全的控制即可。

将 Account 类改为如下形式，它就是线程安全的：

importthreadingimporttimeclassAccount:#定义构造器

def __init__(self, account_no, balance):#封装账户编号、账户余额的两个成员变量

self.account_no =account_no

self._balance=balance

self.lock=threading.RLock()#因为账户余额不允许随便修改，所以只为self._balance提供getter方法

defgetBalance(self):returnself._balance#提供一个线程安全的draw()方法来完成取钱操作

defdraw(self, draw_amount):#加锁

self.lock.acquire()try:#账户余额大于取钱数目

if self._balance >=draw_amount:#吐出钞票

print(threading.current_thread().name\+ "取钱成功！吐出钞票:" +str(draw_amount))

time.sleep(0.001)#修改余额

self._balance -=draw_amountprint("\t余额为:" +str(self._balance))else:print(threading.current_thread().name\+ "取钱失败！余额不足！")finally:#修改完成，释放锁

self.lock.release()

上面程序中的定义了一个 RLock 对象。在程序中实现 draw() 方法时，进入该方法开始执行后立即请求对 RLock 对象加锁，当执行完 draw() 方法的取钱逻辑之后，程序使用 finally 块来确保释放锁。

程序中 RLock 对象作为同步锁，线程每次开始执行 draw() 方法修改 self.balance 时，都必须先对 RLock 对象加锁。当该线程完成对 self._balance 的修改，将要退出 draw() 方法时，则释放对 RLock 对象的锁定。这样的做法完全符合“加锁→修改→释放锁”的安全访问逻辑。

当一个线程在 draw() 方法中对 RLock 对象加锁之后，其他线程由于无法获取对 RLock 对象的锁定，因此它们同时执行 draw() 方法对 self._balance 进行修改。这意味着，并发线程在任意时刻只有一个线程可以进入修改共享资源的代码区(也被称为临界区)，所以在同一时刻最多只有一个线程处于临界区内，从而保证了线程安全。

为了保证 Lock 对象能真正“锁定”它所管理的 Account 对象，程序会被编写成每个 Account 对象有一个对应的 Lock(就像一个房间有一个锁一样)。

上面的 Account 类增加了一个代表取钱的 draw() 方法，并使用 Lock 对象保证该 draw() 方法的线程安全，而且取消了 setBalance() 方法(避免程序直接修改 self._balance 成员变量)，因此线程执行体只需调用 Account 对象的 draw() 方法即可执行取钱操作。

下面程序创建并启动了两个取钱线程：

importthreadingimportAccount#定义一个函数来模拟取钱操作

defdraw(account, draw_amount):#直接调用account对象的draw()方法来执行取钱操作

account.draw(draw_amount)#创建一个账户

acct = Account.Account("1234567" , 1000)#模拟两个线程对同一个账户取钱

threading.Thread(name='甲', target=draw , args=(acct , 800)).start()

threading.Thread(name='乙', target=draw , args=(acct , 800)).start()

上面程序中代表线程执行体的 draw() 函数无须自己实现取钱操作，而是直接调用 account 的 draw() 方法来执行取钱操作。由于 draw() 方法己经使用 RLock 对象实现了线程安全，因此上面程序就不会导致线程安全问题。

多次重复运行上面程序，总可以看到如图 2 所示的运行结果。

甲取钱成功！吐出钞票:800余额为:200乙取钱失败！余额不足！

Process finished with exit code 0