iOS線程死鎖

網站建設哪家好，找創新互聯！專注于網頁設計、網站建設、微信開發、小程序設計、集團企業網站建設等服務項目。為回饋新老客戶創新互聯還提供了榆次免費建站歡迎大家使用！

前言：

    在chat view的開發過程中，添加了“混合標簽添加與顯示”，app出現發送圖片會出現卡死的情況，但過了大約30～40 second后會恢復正常。

問題分析：

    因為沒有任何報錯與提示，只能根據表面現象慢慢分析，經過多次測試與觀察得出以下規律：

    （1）發送表情與文本不會發生該情況，只有發送圖片才會發生app界面卡死的情況。（主線程阻塞，與大文件上傳有關）
     （2）app卡死一定時間后會恢復正常，但時間不定，大約范圍在30～40 second。（主線程解除阻塞，與系統某些機制有關）
     （3）當界面中有gif圖時才會發生，界面中全是移動端本地圖片是能順利發送。（與gif下載有關）

    根據上述現象，可以總結為：主線程阻塞，過后因通信通信失敗而阻塞解除。

    因為與gif圖的下載有關，于是分析gif的下載實現，gif圖的下載由以下代碼實現。

       NSData *gifImageData = [NSDatadataWithContentsOfURL:model.imageRemoteURL];
        FLAnimatedImage *FLAImage = [FLAnimatedImageanimatedImageWithGIFData:gifImageData];

    其中，關于NSData的靜態方法dataWithContentsOfURL的說明中有以下使用說明。

Important
Do not use this synchronous method to request network-based URLs. For network-based URLs, this method can block the current thread for tens of seconds on a slow network, resulting in a poor user experience, and in iOS, may cause your app to be terminated.

    這里說明了要盡量避免使用dataWithContentsOfURL從網絡下載資源，因為它會阻塞當前線程，若下載的文件比較大而網絡又不好就會帶來很差的用戶體驗，對于iOS設備還可能引起app被迫終止。

雖然只需要把dataWithContentsOfURL放置到別的線程中實現，又或者使用NSURLConnect、NSURLSession中的異步請求方法也能解決問題，但本質上引起這問題是因為調用dataWithContentsOfURL時網絡環境差嗎？

明顯不是，因為測試環境是模擬器，模擬器的cpu、網絡通信是比真機要好的，只有GPU是不如真機。而且問題的出現規律是固定。

但dataWithContentsOfURL已經解析了為什么主線程阻塞，那么現在需要解析為什么會阻塞那么長的時間。

    CPU分析結果：
     
     

      圖中的標記的那段是發生異常情況時的CPU的情況。從CPU圖上可以更加肯定線程是并沒有死掉的，而且進入了無法響應的狀態，因此可以判斷出發生線程死鎖的情況。

線程死鎖     

    死鎖的概念：

死鎖是進程死鎖的簡稱，是由Dijkstra于1965年研究銀行家算法時首先提出來的。它是計算機操作系統乃至并發程序設計中最難處理的問題之一。實際上，死鎖問題不僅在計算機系統中存在，在我們日常生活中它也廣泛存在。

我們先看看這樣一個生活中的例子：在一條河上有一座橋，橋面較窄，只能容納一輛汽車通過，無法讓兩輛汽車并行。如果有兩輛汽車A和B分別由橋的兩端駛上該橋，則對于A車來說，它走過橋面左面的一段路（即占有了橋的一部分資源），要想過橋還須等待B車讓出右邊的橋面，此時A車不能前進；對于B車來說，它走過橋面右邊的一段路（即占有了橋的一部分資源），要想過橋還須等待A車讓出左邊的橋面，此時B車也不能前進。兩邊的車都不倒車，結果造成互相等待對方讓出橋面，但是誰也不讓路，就會無休止地等下去。這種現象就是死鎖。如果把汽車比做進程，橋面作為資源，那麼上述問題就描述為：進程A占有資源R1，等待進程B占有的資源Rr；進程B占有資源Rr，等待進程A占有的資源R1。而且資源R1和Rr只允許一個進程占用，即：不允許兩個進程同時占用。結果，兩個進程都不能繼續執行，若不采取其它措施，這種循環等待狀況會無限期持續下去，就發生了進程死鎖。

    上圖是一張描述一個簡單的死鎖模型的圖，首先Thread1鎖定占有資源Y，Thread2鎖定占有資源X，但同時相互向對方請求資源，因此都無法釋放自身資源去訪問下一個資源，結果兩個線程相互阻塞。

死鎖的四個充分必要條件

    從以上分析可見，如果在計算機系統中同時具備下面四個必要條件時，那麼會發生死鎖。換句話說，只要下面四個條件有一個不具備，系統就不會出現死鎖。

   〈1〉互斥條件。即某個資源在一段時間內只能由一個進程占有，不能同時被兩個或兩個以上的進程占有。這種獨占資源如CD-ROM驅動器，打印機等等，必須在占有該資源的進程主動釋放它之后，其它進程才能占有該資源。這是由資源本身的屬性所決定的。如獨木橋就是一種獨占資源，兩方的人不能同時過橋。

   〈2〉不可搶占條件。進程所獲得的資源在未使用完畢之前，資源申請者不能強行地從資源占有者手中奪取資源，而只能由該資源的占有者進程自行釋放。如過獨木橋的人不能強迫對方后退，也不能非法地將對方推下橋，必須是橋上的人自己過橋后空出橋面（即主動釋放占有資源），對方的人才能過橋。

   〈3〉占有且申請條件。進程至少已經占有一個資源，但又申請新的資源；由于該資源已被另外進程占有，此時該進程阻塞；但是，它在等待新資源之時，仍繼續占用已占有的資源。還以過獨木橋為例，甲乙兩人在橋上相遇。甲走過一段橋面（即占有了一些資源），還需要走其余的橋面（申請新的資源），但那部分橋面被乙占有（乙走過一段橋面）。甲過不去，前進不能，又不后退；乙也處于同樣的狀況。

   〈4〉循環等待條件。存在一個進程等待序列{P1，P2，...，Pn}，其中P1等待P2所占有的某一資源，P2等待P3所占有的某一源，......，而Pn等待P1所占有的的某一資源，形成一個進程循環等待環。就像前面的過獨木橋問題，甲等待乙占有的橋面，而乙又等待甲占有的橋面，從而彼此循環等待。

上面我們提到的這四個條件在死鎖時會同時發生。也就是說，只要有一個必要條件不滿足，則死鎖就可以排除。

項目中死鎖的形成與解決

    根據以上理論，以及斷點調試，可以分析得項目的形成，如下圖所描述。

因此只要讓同步下載時不會掛起主線程就可以避免線程死鎖的情況發生。因此項目中使用NSURLConnet的同步請求方法實現下載即可， 因為它不會掛起主線程，還能讓其他線程往主線程中添加代碼塊block。

感謝閱讀，希望能幫助到大家，謝謝大家對本站的支持！

另外有需要云服務器可以了解下創新互聯建站m.newbst.com，海內外云服務器15元起步，三天無理由+7*72小時售后在線，公司持有idc許可證，提供“云服務器、裸金屬服務器、高防服務器、香港服務器、美國服務器、虛擬主機、免備案服務器”等云主機租用服務以及企業上云的綜合解決方案，具有“安全穩定、簡單易用、服務可用性高、性價比高”等特點與優勢，專為企業上云打造定制，能夠滿足用戶豐富、多元化的應用場景需求。

當前文章：IOS線程死鎖詳細介紹-創新互聯
文章鏈接：http://m.newbst.com/article6/dioiig.html

成都網站建設公司_創新互聯，為您提供網站導航、ChatGPT、營銷型網站建設、企業網站制作、靜態網站、品牌網站建設

廣告

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯