小編給大家分享一下iOS中如何實(shí)現(xiàn)多網(wǎng)絡(luò)請求的線程安全，相信大部分人都還不怎么了解，因此分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后大有收獲，下面讓我們一起去了解一下吧！

創(chuàng)新互聯(lián)建站長期為1000多家客戶提供的網(wǎng)站建設(shè)服務(wù)，團(tuán)隊(duì)從業(yè)經(jīng)驗(yàn)10年，關(guān)注不同地域、不同群體，并針對不同對象提供差異化的產(chǎn)品和服務(wù)；打造開放共贏平臺，與合作伙伴共同營造健康的互聯(lián)網(wǎng)生態(tài)環(huán)境。為沈北新企業(yè)提供專業(yè)的網(wǎng)站設(shè)計、成都網(wǎng)站制作，沈北新網(wǎng)站改版等技術(shù)服務(wù)。擁有10多年豐富建站經(jīng)驗(yàn)和眾多成功案例,為您定制開發(fā)。

在iOS 網(wǎng)絡(luò)編程有一種常見的場景是：我們需要并行處理二個請求并且在都成功后才能進(jìn)行下一步處理。下面是部分常見的處理方式，但是在使用過程中也很容易出錯：

• DispatchGroup：通過 GCD 機(jī)制將多個請求放到一個組內(nèi)，然后通過DispatchGroup.wait()和DispatchGroup.notify()進(jìn)行成功后的處理。

• OperationQueue：為每一個請求實(shí)例化一個 Operation 對象，然后將這些對象添加到 OperationQueue ，并且根據(jù)它們之間的依賴關(guān)系決定執(zhí)行順序。

• 同步 DispatchQueue：通過同步隊(duì)列和 NSLock 機(jī)制避免數(shù)據(jù)競爭，實(shí)現(xiàn)異步多線程中同步安全訪問。

• 第三方類庫：Futures/Promises 以及響應(yīng)式編程提供了更高層級的并發(fā)抽象。

在多年的實(shí)踐過程中，我意識到上面這些方法這些方法都存在一定的缺陷。另外，要想完全正確的使用這些類庫還是有些困難。

并發(fā)編程中的挑戰(zhàn)

使用并發(fā)的思維思考問題很困難：大多數(shù)時候，我們會按照讀故事的方式來閱讀代碼：從第一行到最后一行。如果代碼的邏輯不是線性的話，可能會給我們造成一定的理解難度。在單線程環(huán)境下，調(diào)試和跟蹤多個類和框架的程序執(zhí)行已經(jīng)是非常頭疼的一件事了，多線程環(huán)境下這種情況簡直不敢想象。

數(shù)據(jù)競爭問題：在多線程并發(fā)環(huán)境下，數(shù)據(jù)讀取操作是線程安全的而寫操作則是非線程安全。如果發(fā)生了多個線程同時對某個內(nèi)存進(jìn)行寫操作的話，則會發(fā)生數(shù)據(jù)競爭導(dǎo)致潛在數(shù)據(jù)錯誤。

理解多線程環(huán)境下的動態(tài)行為本身就不是一件容易的事，找出導(dǎo)致數(shù)據(jù)競爭的線程就更為麻煩。雖然我們可以通過互斥鎖機(jī)制解決數(shù)據(jù)競爭問題，但是對于可能修改的代碼來說互斥鎖機(jī)制的維護(hù)會是一件非常困難的事。

難以測試：并發(fā)環(huán)境下很多問題并不會在開發(fā)過程中顯現(xiàn)出來。雖然 Xcode 和 LLVM 提供了Thread Sanitizer 這類工具用于檢查這些問題，但是這些問題的調(diào)試和跟蹤依然存在很大的難度。因?yàn)椴l(fā)環(huán)境下除了代碼本身的影響外，應(yīng)用也會受到系統(tǒng)的影響。

處理并發(fā)情形的簡單方法

考慮到并發(fā)編程的復(fù)雜性，我們應(yīng)該如何解決并行的多個請求？

最簡單的方式就是避免編寫并行代碼而是講多個請求線性的串聯(lián)在一起：

let session = URLSession.shared

session.dataTask(with: request1) { data, response, error in
 // check for errors
 // parse the response data

 session.dataTask(with: request2) { data, response error in
  // check for errors
  // parse the response data

  // if everything succeeded...
  callbackQueue.async {
   completionHandler(result1, result2)
  }
 }.resume()
}.resume()

為了保持代碼的簡潔，這里忽略了很多的細(xì)節(jié)處理，例如：錯誤處理以及請求取消操作。但是這樣將并無關(guān)聯(lián)的請求線性排序其實(shí)暗藏著一些問題。例如，如果服務(wù)端支持 HTTP/2 協(xié)議的話，我們就沒發(fā)利用 HTTP/2 協(xié)議中通過同一個鏈接處理多個請求的特性，而且線性處理也意味著我們沒有好好利用處理器的性能。

關(guān)于 URLSession 的錯誤認(rèn)知

為了避免可能的數(shù)據(jù)競爭和線程安全問題，我將上面的代碼改寫為了嵌套請求。也就是說如果將其改為并發(fā)請求的話：請求將不能進(jìn)行嵌套，兩個請求可能會對同一塊內(nèi)存進(jìn)行寫操作而數(shù)據(jù)競爭非常難以重現(xiàn)和調(diào)試。

解決改問題的一個可行辦法是通過鎖機(jī)制：在一段時間內(nèi)只允許一個線程對共享內(nèi)存進(jìn)行寫操作。鎖機(jī)制的執(zhí)行過程也非常簡單：請求鎖、執(zhí)行代碼、釋放鎖。當(dāng)然要想完全正確使用鎖機(jī)制還是有一些技巧的。

但是根據(jù) URLSession 的文檔描述，這里有一個并發(fā)請求的更簡單解決方案。

init(configuration: URLSessionConfiguration,
   delegate: URLSessionDelegate?,
   delegateQueue queue: OperationQueue?)

[…]

queue : An operation queue for scheduling the delegate calls and completion handlers. The queue should be a serial queue, in order to ensure the correct ordering of callbacks. If nil, the session creates a serial operation queue for performing all delegate method calls and completion handler calls.

這意味所有 URLSession 的實(shí)例對象包括 URLSession.shared 單例的回調(diào)并不會并發(fā)執(zhí)行，除非你明確的傳人了一個并發(fā)隊(duì)列給參數(shù) queue 。

URLSession 拓展并發(fā)支持

基于上面對 URLSession 的新認(rèn)知，下面我們對其進(jìn)行拓展讓它支持線程安全的并發(fā)請求（完成代碼地址）。

enum URLResult {
 case response(Data, URLResponse)
 case error(Error, Data?, URLResponse?)
}

extension URLSession {
 @discardableResult
 func get(_ url: URL, completionHandler: @escaping (URLResult) -> Void) -> URLSessionDataTask
}

// Example

let zen = URL(string: "https://api.github.com/zen")!
session.get(zen) { result in
 // process the result
}

首先，我們使用了一個簡單的 URLResult 枚舉來模擬我們可以在 URLSessionDataTask 回調(diào)中獲得的不同結(jié)果。該枚舉類型有利于我們簡化多個并發(fā)請求結(jié)果的處理。這里為了文章的簡潔并沒有貼出URLSession.get(_:completionHandler:)方法的完整實(shí)現(xiàn)，該方法就是使用 GET 方法請求對應(yīng)的 URL 并自動執(zhí)行resume()最后將執(zhí)行結(jié)果封裝成 URLResult 對象。

@discardableResult
func get(_ left: URL, _ right: URL, completionHandler: @escaping (URLResult, URLResult) -> Void) -> (URLSessionDataTask, URLSessionDataTask) {
 
}

該段 API 代碼接受兩個 URL 參數(shù)并返回兩個 URLSessionDataTask 實(shí)例。下面代碼是函數(shù)實(shí)現(xiàn)的第一段：

 precondition(delegateQueue.maxConcurrentOperationCount == 1,
  "URLSession's delegateQueue must be configured with a maxConcurrentOperationCount of 1.")

因?yàn)樵趯?shí)例化 URLSession 對象時依舊可以傳入并發(fā)的 OperationQueue 對象，所以這里我們需要使用上面這段代碼將這種情況排除掉。

var results: (left: URLResult?, right: URLResult?) = (nil, nil)

func continuation() {
 guard case let (left?, right?) = results else { return }
 completionHandler(left, right)
}

將這段代碼繼續(xù)添加到實(shí)現(xiàn)中，其中定義了一個表示返回結(jié)果的元組變量 results 。另外，我們還在函數(shù)內(nèi)部定義了另一個工具函數(shù)用于檢查是否兩個請求都已經(jīng)完成結(jié)果處理。

let left = get(left) { result in
 results.left = result
 continuation()
}

let right = get(right) { result in
 results.right = result
 continuation()
}

return (left, right)

最后將這段代碼追加到實(shí)現(xiàn)中，其中我們分別對兩個 URL 進(jìn)行了請求并在請求都完成后一次返回了結(jié)果。值得注意的是這里我們通過兩次執(zhí)行continuation()來判斷請求是否全部完成：

• 第一次執(zhí)行continuation()時因?yàn)槠渲幸粋€請求并未完成結(jié)果為 nil 所以回調(diào)函數(shù)并不會執(zhí)行。

• 第二次執(zhí)行的時候兩個請求全部完成，執(zhí)行回調(diào)處理。

接下來我們可以通過簡單的請求來測試下這段代碼：

extension URLResult {
 var string: String? {
  guard case let .response(data, _) = self,
  let string = String(data: data, encoding: .utf8)
  else { return nil }
  return string
 }
}

URLSession.shared.get(zen, zen) { left, right in
 guard case let (quote1?, quote2?) = (left.string, right.string)
 else { return }

 print(quote1, quote2, separator: "\n")
 // Approachable is better than simple.
 // Practicality beats purity.
}

并行悖論

我發(fā)現(xiàn)解決并行問題最簡單最優(yōu)雅的方法就是盡可能的少使用并發(fā)編程，而且我們的處理器非常適合執(zhí)行那些線性代碼。但是如果將大的代碼塊或任務(wù)拆分為多個并行執(zhí)行的小代碼塊和任務(wù)將會讓代碼變得更加易讀和易維護(hù)。

以上是“iOS中如何實(shí)現(xiàn)多網(wǎng)絡(luò)請求的線程安全”這篇文章的所有內(nèi)容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內(nèi)容對大家有所幫助，如果還想學(xué)習(xí)更多知識，歡迎關(guān)注創(chuàng)新互聯(lián)網(wǎng)站建設(shè)公司行業(yè)資訊頻道！

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

當(dāng)前名稱：iOS中如何實(shí)現(xiàn)多網(wǎng)絡(luò)請求的線程安全-創(chuàng)新互聯(lián)
文章轉(zhuǎn)載：http://www.chinadenli.net/article30/dccdpo.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供企業(yè)建站、網(wǎng)站營銷、建站公司、全網(wǎng)營銷推廣、響應(yīng)式網(wǎng)站、做網(wǎng)站

廣告

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