本篇內(nèi)容主要講解“Python線程和鎖是什么”,感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷,實用性強。下面就讓小編來帶大家學習“Python線程和鎖是什么”吧!
成都創(chuàng)新互聯(lián)專注為客戶提供全方位的互聯(lián)網(wǎng)綜合服務,包含不限于成都網(wǎng)站制作、成都網(wǎng)站建設、磁縣網(wǎng)絡推廣、小程序設計、磁縣網(wǎng)絡營銷、磁縣企業(yè)策劃、磁縣品牌公關、搜索引擎seo、人物專訪、企業(yè)宣傳片、企業(yè)代運營等,從售前售中售后,我們都將竭誠為您服務,您的肯定,是我們最大的嘉獎;成都創(chuàng)新互聯(lián)為所有大學生創(chuàng)業(yè)者提供磁縣建站搭建服務,24小時服務熱線:18980820575,官方網(wǎng)址:muchs.cn
概述
線程和鎖是硬件底層的軟件定義形式化,因此包含最簡單的可能并發(fā)模型。它構成了其他構建在其頂層的并發(fā)抽象基礎,因此理解這一點很重要。然而,直接在這些基礎上構建可靠,可擴展的系統(tǒng)是很困難的或著說是不可能的。
雖然大多數(shù)語言都支持線程和鎖,但CPython仍然使用全局解釋器鎖來防止線程同時訪問共享內(nèi)存,因為CPython的內(nèi)存管理是非線程安全的。雖然阻塞操作發(fā)生在GIL之外并且可能提高性能,但是線程切換所需的系統(tǒng)調(diào)用開銷可能會降低性能。這意味著Python中的線程主要用于I/O受限的場景,而不是CPU受限的場景。
說句題外話,我提到了CPython,因為Python規(guī)范的其他部分實現(xiàn),例如Jython,沒有全局解釋器鎖。然而,這些實現(xiàn)在實踐中并沒有被廣泛使用,因為***:沒有人想要支持多Python實現(xiàn),除非他們不得不這樣;第二:它們還不夠豐富;第三:由于需要原生支持C/C++擴展API,Python語言定義與C/C++緊密耦合,與其說是技術規(guī)范不如說是一個參考實現(xiàn)。
Python通過高級模塊threading模塊和低級模塊_thread直接支持線程。想要獲得更多有關這些模塊如何工作的信息,可以在線獲取源代碼。
入門
Python中典型的單線程“Hello World”執(zhí)行非常簡單:
多線程模擬并沒有太大的不同:
基于我有限數(shù)量的測試,上面的腳本運行結果如下所示:
我用了get_ident()打印“線程標識符”(一個魔法值,除了在運行時消除不同線程之間的歧義之外,沒有任何意義)。你可以看到在某些情況下,線程標識符是如何不同的,而在其他一些情況下,線程標識符又是相同的。相同的線程標識符并不意味著仍工作在同一個線程上,但如果工作不重疊并且不需要不同的線程標識符,Python會重新使用該標識符。
陷阱:時序性和一致性
如果你用threading.current_thread().getName()將線程標識符與線程名交換,你可能會獲得有序結果,很大的原因可能是因為每個線程使用相同的函數(shù)和源碼路徑,因此,每個線程之間的延遲差異是微不足道的,僅次于解釋器的延遲。然而,這并不意味著有序執(zhí)行能夠得到保證;這是WikiBooks上“Python Programming”的一個例子,其中每個線程的創(chuàng)建和每個線程的執(zhí)行具有明顯不同的時序性:
以下結果是同一個樣本運行的輸出:
這日志表示線程創(chuàng)建/執(zhí)行是交錯的。由于增加功能的可變性增加,隨著線程創(chuàng)建和執(zhí)行之間的時序越來越不一致,這些結果將變得越來越不可預測。但原理仍然是相同的;使用多個線程時無法保證一致的行為。
陷阱:訪問共享內(nèi)存
當不同的線程訪問共享內(nèi)存時,這可能導致不正確的行為。你可以擴展此示例以在使用多個線程進行計數(shù)時查看競爭條件:
這會在一次示例運行時生成如下輸出:
此結果因創(chuàng)建的線程數(shù)而異,但你可以看到結果28與預期值100有多大區(qū)別。Counter().count是非線程安全的,在這里進行了演示(如果你有與我不同的機器,你可能會得到與28不同的結果)。如果遇到競爭條件,沒有足夠的日志記錄,可能很難找到相關的代碼部分。
陷阱:死鎖
當兩個代理嘗試獲取共享內(nèi)存的相同區(qū)域時,最終就會發(fā)生死鎖。當在處理線程和鎖的低級抽象時,唯一的解決方案是確保每個代理有一種方法能正確地管理其鎖,或者具有鎖協(xié)調(diào)的整體規(guī)范。例如,用餐哲學問題強調(diào)了流程同步的重要性。Rosetta Code的用餐哲學python解決方案解決了這個同步問題:如果你(代理)不能及時獲取這兩個分叉,你可以釋放你已經(jīng)擁有的任何叉子,以便另一個代理可以同時獲得這兩個叉子。
此方法不排除其他鎖定方法,像鎖定順序,或涉及流程同步的系統(tǒng)設計,像使用信號量的生產(chǎn)者-消費者模型,但在Python中可能不如在其他語言中普遍。
陷阱:異形方法和依賴關系
如果要在Python應用程序中應用多線程,那么你希望保證整個堆棧的正確性,你必須手動驗證核實線程安全性和依賴項的線程模型。有些為企業(yè)級多服務環(huán)境使用而設計的依賴項,例如redis,可以在設計階段首先考慮它們的并發(fā)模型(請參閱黑客新聞antirez關于多線程版本redis的評論)。有些依賴可能不會;使用boto2時,并行使用multiprocessing.pool.Pool從S3并行下載文件時,我可能遇到了死鎖,這需要重寫一個函數(shù)。因此,另一個依賴性的困難出現(xiàn)了;它們無法被同化,這意味著如果你在你的應用使用依賴模型之前沒有驗證所有將使用的依賴關系,那么在嘗試為特定用途添加依賴項時,你可能陷入項目的死胡同。
多線程日志記錄
如果你選擇使用Python中的原生線程模型,你可能會驚喜地發(fā)現(xiàn)logging模塊不僅是線程安全的,而且還支持從任何特定線程或進程進行日志記錄(示例在logging手冊)。然后,難點是在你的應用程序中哪里更可能觸發(fā)異常,這如何影響你的線程模型以及確保在這些代碼段周圍進行可靠的日志記錄。將日志添加到你的應用可能會產(chǎn)生不小的延遲,正如pylint通過警告模塊logging-lazy-interpolation通知你那樣,這也可能會給你的線程模型帶來困難。
concurrent.futures
在撰寫這篇文章時發(fā)現(xiàn)Python
multiprocessing.pool.ThreadPool實現(xiàn)從未被記錄或測試過,因為它從未完成,這讓我感覺非常不愉快。它在Python3.7中仍然還是這樣,因為它出現(xiàn)在GitHub鏡像的源代碼中。鑒于全局解釋器鎖的無所不在,以及未來并發(fā)程序主要是并行I/O相關的工作,使用Python3.x中提供的像concurrent.futures.Executor或類似的新異步模式可能更有意義,因為他們更全面。我沒有使用過這個模塊,但我想與multiprocessing相比,它不會產(chǎn)生顯著的性能損耗。
到此,相信大家對“Python線程和鎖是什么”有了更深的了解,不妨來實際操作一番吧!這里是創(chuàng)新互聯(lián)網(wǎng)站,更多相關內(nèi)容可以進入相關頻道進行查詢,關注我們,繼續(xù)學習!
文章題目:Python線程和鎖是什么
網(wǎng)頁路徑:http://muchs.cn/article10/joosdo.html
成都網(wǎng)站建設公司_創(chuàng)新互聯(lián),為您提供網(wǎng)頁設計公司、微信小程序、網(wǎng)站導航、微信公眾號、ChatGPT、關鍵詞優(yōu)化
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時需注明來源: 創(chuàng)新互聯(lián)