小編寫這篇文章的一個主要目的,主要是來給大家介紹關于python的一些事情,python的使用場景是比較的多的,主要涉及到其中的一些方方面面,那么,它的并發場景使用方法是什么呢?下面就給大家詳細解答下。
前言
如果你學過操作系統,那么對于鎖應該不陌生。鎖的含義是線程鎖,可以用來指定某一個邏輯或者是資源同一時刻只能有一個線程訪問。這個很好理解,就好像是有一個房間被一把鎖鎖住了,只有拿到鑰匙的人才能進入。每一個人從房間門口拿到鑰匙進入房間,出房間的時候會把鑰匙再放回到門口。這樣下一個到門口的人就可以拿到鑰匙了。這里的房間就是某一個資源或者是一段邏輯,而拿取鑰匙的人其實指的是一個線程。
加鎖的原因
我們明白了鎖的原理,不禁有了一個問題,我們為什么需要鎖呢,它在哪些場景當中會用到呢?
其實它的使用場景非常廣,我們舉一個非常簡單的例子,就是淘寶買東西。我們都知道商家的庫存都是有限的,賣掉一個少一個。假如說當前某個商品庫存只剩下一個,但當下卻有兩個人同時購買。兩個人同時購買也就是有兩個請求同時發起購買請求,如果我們不加鎖的話,兩個線程同時查詢到商品的庫存是1,大于0,進行購買邏輯之后,同時減一。由于兩個線程同時執行,所以最后商品的庫存會變成-1。
顯然商品的庫存不應該是一個負數,所以我們需要避免這種情況發生。通過加鎖可以完美解決這個問題。我們規定一次只能有一個線程發起購買的請求,那么這樣當一個線程將庫存減到0的時候,第二個請求就無法修改了,就保證了數據的準確性。
代碼實現
那么在Python當中,我們怎么樣來實現這個鎖呢?
其實很簡單,threading庫當中已經為我們提供了線程的工具,我們直接拿過來用就可以了。我們通過使用threading當中的Lock對象,可以很輕易的實現方法加鎖的功能。
import threading class PurchaseRequest: ''' 初始化庫存與鎖 ''' def __init__(self,initial_value=0): self._value=initial_value self._lock=threading.Lock() def incr(self,delta=1): ''' 加庫存 ''' self._lock.acquire() self._value+=delta self._lock.release() def decr(self,delta=1): ''' 減庫存 ''' self._lock.acquire() self._value-=delta self._lock.release()
我們從代碼當中就可以很輕易的看出Lock這個對象的使用方法,我們在進入加鎖區(資源搶占區)之前,我們需要先使用lock.acquire()方法獲取鎖。Lock對象可以保證同一時刻只能有一個線程獲取鎖,只有獲取了鎖之后才會繼續往下執行。當我們執行完成之后,我們需要把鎖“放回門口”,所以需要再調用一下release方法,表示鎖的釋放。
這里有一個小問題是很多程序員在編程的時候總是會忘記release,導致不必要的bug,而且這種分布式場景當中的bug很難通過測試發現。因為測試的時候往往很難測試并發場景,code review的時候也很容易忽略,因此一旦泄露了還是挺難發現的。
為了解決這個問題,Lock還提供了一種改進的用法,就是使用with語句。with語句我們之前在使用文件的時候用到過,使用with可以替我們完成try catch以及資源回收等工作,我們只管用就完事了。這里也是一樣,使用with之后我們就可以不用管鎖的申請和釋放了,直接寫代碼就行,所以上面的代碼可以改寫成這樣:
import threading class PurchaseRequest: ''' 初始化庫存與鎖 ''' def __init__(self,initial_value=0): self._value=initial_value self._lock=threading.Lock() def incr(self,delta=1): ''' 加庫存 ''' with self._lock: self._value+=delta def decr(self,delta=1): ''' 減庫存 ''' with self._lock: self._value-=delta
這樣看起來是不是清爽很多?
可重入鎖
上面介紹的只是最簡單的鎖,我們經常使用的往往是可重入鎖。
什么叫可重入鎖呢?簡單解釋一下,就是在一個線程已經持有了鎖的情況下,它可以再次進入被加鎖的區域。但是既然線程還持有鎖沒有釋放,那么它不應該還是在加鎖區域嗎,怎么會有需要再次進入被加鎖區域的情況呢?其實是有的,道理也很簡單,就是遞歸。
我們把上面的例子稍微改一點點,就完全不一樣了。
import threading class PurchaseRequest: ''' 初始化庫存與鎖 ''' def __init__(self,initial_value=0): self._value=initial_value self._lock=threading.Lock() def incr(self,delta=1): ''' 加庫存 ''' with self._lock: self._value+=delta def decr(self,delta=1): ''' 減庫存 ''' with self._lock: self.incr(-delta) 我們關注一下上面的decr方法,我們用incr來代替了原本的邏輯實現了decr。但是有一個問題是decr也是一個加鎖的方法,需要前一個鎖釋放了才能進入。但它已經持有了鎖了,那么這種情況下就會發生死鎖。 我們只需要把Lock換成可重入鎖就可以解決這個問題,只需要修改一行代碼。 import threading class PurchaseRequest: ''' 初始化庫存與鎖 我們使用RLock代替了Lock,也可重入鎖代替了普通鎖 ''' def __init__(self,initial_value=0): self._value=initial_value self._lock=threading.RLock() def incr(self,delta=1): ''' 加庫存 ''' with self._lock: self._value+=delta def decr(self,delta=1): ''' 減庫存 ''' with self._lock: self.incr(-delta)
總結
文章介紹了Python當中鎖的使用方法,以及可重入鎖的概念。在并發場景下開發和調試都是一個比較困難的工作,稍微不小心就會踩到各種各樣的坑,死鎖只是其中一種比較常見并且比較容易解決的問題,除此之外還有很多其他各種各樣的問題。
綜上所述,這篇文章就給大家介紹到這里了,希望可以給大家帶來幫助。
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/128418.html
摘要:測試吞吐量的時候,是通過每一種實現都重復測試超過次,每一次都運行秒以上,以保證系統足夠預熱,下面的結果都是第次之后平均每秒吞吐量。以我的經驗看,教學和開發中的無鎖算法,不僅能顯著改善吞吐量同時他們也提供更低的延遲。 上周在由Heinz Kabutz通過JCrete?組織的開放空間會議(unconference)上,我參加一個新的java規范 JSR166?StampedLock 的審查...
摘要:如果某線程并未使用很多操作,它會在自己的時間片內一直占用處理器和。在中使用線程在和等大多數類系統上運行時,支持多線程編程。守護線程另一個避免使用模塊的原因是,它不支持守護線程。 這一篇是Python并發的第四篇,主要介紹進程和線程的定義,Python線程和全局解釋器鎖以及Python如何使用thread模塊處理并發 引言&動機 考慮一下這個場景,我們有10000條數據需要處理,處理每條...
摘要:有可能,會造成優先級反轉或者饑餓現象。悲觀鎖在中的使用,就是利用各種鎖。對于而言,其是獨享鎖。偏向鎖,顧名思義,它會偏向于第一個訪問鎖的線程,大多數情況下鎖不僅不存在多線程競爭,而且總是由同一線程多次獲得。 理解鎖的基礎知識 如果想要透徹的理解java鎖的來龍去脈,需要先了解以下基礎知識。 基礎知識之一:鎖的類型 按照其性質分類 公平鎖/非公平鎖 公平鎖是指多個線程按照申請鎖的順序來獲...
摘要:中關于線程的標準庫是,之前在版本中的在之后更名為,無論是還是都應該盡量避免使用較為底層的而應該使用。而與線程相比,協程尤其是結合事件循環無論在編程模型還是語法上,看起來都是非常友好的單線程同步過程。 項目地址:https://git.io/pytips 要說到線程(Thread)與協程(Coroutine)似乎總是需要從并行(Parallelism)與并發(Concurrency)談起...
摘要:此時線程和會再有一個線程能夠獲取寫鎖,假設是,如果不采用再次驗證的方式,此時會再次查詢數據庫。而實際上線程已經把緩存的值設置好了,完全沒有必要再次查詢數據庫。 大家知道了Java中使用管程同步原語,理論上可以解決所有的并發問題。那 Java SDK 并發包里為什么還有很多其他的工具類呢?原因很簡單:分場景優化性能,提升易用性 今天我們就介紹一種非常普遍的并發場景:讀多寫少場景。實際工作...
閱讀 911·2023-01-14 11:38
閱讀 878·2023-01-14 11:04
閱讀 740·2023-01-14 10:48
閱讀 1982·2023-01-14 10:34
閱讀 942·2023-01-14 10:24
閱讀 819·2023-01-14 10:18
閱讀 499·2023-01-14 10:09
閱讀 572·2023-01-14 10:02