死鎖的原理非常簡單，用一句話就可以描述完。就是當多線程訪問多個鎖的時候，不同的鎖被不同的線程持有，它們都在等待其他線程釋放出鎖來，于是便陷入了永久等待。比如A線程持有1號鎖，等待2號鎖，B線程持有2號鎖等待1號鎖，那么它們永遠也等不到執行的那天，這種情況就叫做死鎖。

關于死鎖有一個著名的問題叫做哲學家就餐問題，有5個哲學家圍坐在一起，他們每個人需要拿到兩個叉子才可以吃飯。如果他們同時拿起自己左手邊的叉子，那么就會永遠等待右手邊的叉子釋放出來。這樣就陷入了永久等待，于是這些哲學家都會餓死。

這是一個很形象的模型，因為在計算機并發場景當中，一些資源的數量往往是有限的。很有可能出現多個線程搶占的情況，如果處理不好就會發生大家都獲取了一個資源，然后在等待另外的資源的情況。

對于死鎖的問題有多種解決方法，這里我們介紹比較簡單的一種，就是對這些鎖進行編號。我們規定當一個線程需要同時持有多個鎖的時候，必須要按照序號升序的順序對這些鎖進行訪問。通過上下文管理器我們可以很容易實現這一點。

上下文管理器

首先我們來簡單介紹一下上下文管理器，上下文管理器我們其實經常使用，比如我們經常使用的 with語句 就是一個上下文管理器的經典使用。當我們通過with語句打開文件的時候，它會自動替我們處理好文件讀取之后的關閉以及拋出異常的處理，可以節約我們大量的代碼。

同樣我們也可以自己定義一個上下文處理器，其實很簡單，我們只需要實現__enter__和__exit__這兩個函數即可。__enter__函數用來實現進入資源之前的操作和處理，那么顯然__exit__函數對應的就是使用資源結束之后或者是出現異常的處理邏輯。有了這兩個函數之后，我們就有了自己的上下文處理類了。

我們來看一個樣例：

class Sample: def __enter__(self): print(’enter resources’) return self def __exit__(self, exc_type, exc_val, exc_tb): print(’exit’) # print(exc_type) # print(exc_val) # print(exc_tb) def doSomething(self): a = 1/1 return adef getSample(): return Sample()if __name__ == ’__main__’: with getSample() as sample: print(’do something’) sample.doSomething()

當我們運行這段代碼的時候，屏幕上打印的結果和我們的預期是一致的。

我們觀察一下__exit__函數，會發現它的參數有4個，后面的三個參數對應的是拋出異常的情況。type對應異常的類型，val對應異常時的輸出值，trace對應異常拋出時的運行堆棧。這些信息都是我們排查異常的時候經常需要用到的信息，通過這三個字段，我們可以根據我們的需要對可能出現的異常進行自定義的處理。

實現上下文管理器并不一定要通過類實現，Python當中也提供了上下文管理的注解，通過使用注解我們可以很方便地實現上下文管理。我們同樣也來看一個例子：

import timefrom contextlib import contextmanager@contextmanagerdef timethis(label): start = time.time() try: yield finally: end = time.time() print(’{}: {}’.format(label, end - start))with timethis(’timer’): pass

在這個方法當中yield之前的部分相當于__enter__函數，yield之后的部分相當于__exit__。如果出現異常會在try語句當中拋出，那么我們編寫except對異常進行處理即可。

避免死鎖

了解了上下文管理器之后，我們要做的就是 在lock的外面包裝一層 ，使得我們在獲取和釋放鎖的時候可以根據我們的需要，對鎖進行排序，按照升序的順序進行持有。

這段代碼源于Python的著名進階書籍《Python cookbook》，非常經典：

from contextlib import contextmanager# 用來存儲local的數據_local = threading.local()@contextmanagerdef acquire(*locks): # 對鎖按照id進行排序 locks = sorted(locks, key=lambda x: id(x)) # 如果已經持有鎖當中的序號有比當前更大的，說明策略失敗 acquired = getattr(_local,’acquired’,[]) if acquired and max(id(lock) for lock in acquired) >= id(locks[0]): raise RuntimeError(’Lock Order Violation’) # 獲取所有鎖 acquired.extend(locks) _local.acquired = acquired try: for lock in locks: lock.acquire() yield finally: # 倒敘釋放 for lock in reversed(locks): lock.release() del acquired[-len(locks):]

這段代碼寫得非常漂亮，可讀性很高，邏輯我們都應該能看懂，但是有一個小問題是這里用到了 threading.local 這個組件。

它是一個多線程場景當中的 共享變量 ，雖然說是共享的，但是對于每個線程來說讀取到的值都是獨立的。聽起來有些難以理解，其實我們可以將它理解成一個dict，dict的key是每一個線程的id，value是一個存儲數據的dict。每個線程在訪問local變量的時候，都相當于先通過線程id獲取了一個獨立的dict，再對這個dict進行的操作。

看起來我們在使用的時候直接使用了_local，這是因為通過線程id先進行查詢的步驟在其中封裝了。不明就里的話可能會覺得有些難以理解。

我們再來看下這個acquire的使用：

x_lock = threading.Lock()y_lock = threading.Lock()def thread_1(): while True: with acquire(x_lock, y_lock): print(’Thread-1’)def thread_2(): while True: with acquire(y_lock, x_lock): print(’Thread-2’)t1 = threading.Thread(target=thread_1)t1.start()t2 = threading.Thread(target=thread_2)t2.start()

運行一下會發現沒有出現死鎖的情況，但如果我們把代碼稍加調整，寫成這樣，那么就會觸發異常了。

def thread_1(): while True: with acquire(x_lock): with acquire(y_lock): print(’Thread-1’)def thread_2(): while True: with acquire(y_lock): with acquire(x_lock): print(’Thread-1’)

因為我們把鎖寫成了層次結構，這樣就沒辦法進行排序保證持有的有序性了，那么就會觸發我們代碼當中定義的異常。

最后我們再來看下哲學家就餐問題，通過我們自己實現的acquire函數我們可以非常方便地解決他們死鎖吃不了飯的問題。

import threadingdef philosopher(left, right): while True: with acquire(left,right): print(threading.currentThread(), ’eating’)# 叉子的數量NSTICKS = 5chopsticks = [threading.Lock() for n in range(NSTICKS)]for n in range(NSTICKS): t = threading.Thread(target=philosopher, args=(chopsticks[n],chopsticks[(n+1) % NSTICKS])) t.start()

關于死鎖的問題，對鎖進行排序 只是其中的一種解決方案 ，除此之外還有很多解決死鎖的模型。比如我們可以讓線程在嘗試持有新的鎖失敗的時候主動放棄所有目前已經持有的鎖，比如我們可以設置機制檢測死鎖的發生并對其進行處理等等。發散出去其實有很多種方法，這些方法起作用的原理各不相同，其中涉及大量操作系統的基礎概念和知識，感興趣的同學可以深入研究一下這個部分，一定會對操作系統以及鎖的使用有一個深刻的認識。

以上就是python 多線程死鎖問題的解決方案的詳細內容，更多關于python 多線程死鎖的資料請關注好吧啦網其它相關文章！