小編給大家分享一下iOS中多線程的經(jīng)典崩潰示例,相信大部分人都還不怎么了解,因此分享這篇文章給大家參考一下,希望大家閱讀完這篇文章后大有收獲,下面讓我們一起去了解一下吧!
網(wǎng)站建設(shè)哪家好,找創(chuàng)新互聯(lián)公司!專注于網(wǎng)頁設(shè)計、網(wǎng)站建設(shè)、微信開發(fā)、小程序定制開發(fā)、集團(tuán)企業(yè)網(wǎng)站建設(shè)等服務(wù)項目。為回饋新老客戶創(chuàng)新互聯(lián)還提供了師宗免費建站歡迎大家使用!0x0 Block 回調(diào)的崩潰
在MRC環(huán)境下,使用Block 來設(shè)置下載成功的圖片。當(dāng)self釋放后,weakSelf變成野指針,接著就悲劇了
__block ViewController *weakSelf = self; [self.imageView imageWithUrl:@"" completedBlock:^(UIImage *image, NSError *error) { NSLog(@"%@",weakSelf.imageView.description); }];
0x1 多線程下Setter 的崩潰
Getter & Setter 寫多了,在單線程的情況下,是沒有問題的。但是在多線程的情況下,可能會崩潰。因為[_imageView release]; 這段代碼可能會被執(zhí)行兩次,oops!
UIKit 不是線程,所以在不是主線程的地方調(diào)用UIKit 的東西,有可能在開發(fā)階段完全沒問題,直接免測。但是一到線上,崩潰系統(tǒng)可能都是你的崩潰日志。Holy shit!
解決辦法:通過hook 住setNeedsLayout,setNeedsDisplay,setNeedsDisplayInRect來檢查當(dāng)前調(diào)用的線程是否是主線程。
- (void)setImageView:(UIImageView *)imageView { if (![_imageView isEqual:imageView]) { [_imageView release]; _imageView = [imageView retain]; } }
0x2 更多Setter 類型的崩潰
property 的屬性,寫的最多的就是nonatomic,一般情況下也是沒有問題的!
@interface ViewController () @property (strong,nonatomic) NSMutableArray *array; @end
跑一下下面這段代碼,你會看到:malloc: error for object 0x7913d6d0: pointer being freed was not allocated
for (int i = 0; i < 100; i++) { dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{ self.array = [[NSMutableArray alloc] init]; }); }
原因就是:對象被重復(fù)relaese 了。查看一下runtime 源碼
解決辦法:屬性聲明為atomic.
一個更為常見的例子:
if(handler == nil) { hander = [[Handler alloc] init]; } return handler;
如果A,B兩個線程同時訪問到if語句, 此時handler == nil
條件滿足, 兩個線程都走到下一句初始化實例.
此時A線程先完成初始化并賦值(這個實例我們叫它a), 然后繼續(xù)往后走到其他邏輯.而這時候, B線程開始做初始化并賦值(這個實例我們叫它b), handler將指向B線程初始化出來的對象. 而A初始化出來的實例a因為引用計數(shù)減少1(減少到0)而被釋放. 但在A線程中, 代碼還會嘗試訪問a所在的地址, 這個地址里的內(nèi)容因為被釋放而變得無法預(yù)測, 從而導(dǎo)致野指針.
問題還有一個很關(guān)鍵的點, 在一個對象的某個方法的調(diào)用過程中, 這個對象的引用計數(shù)并不會增加, 到導(dǎo)致它如果被釋放, 后續(xù)的執(zhí)行過程中對這個對象的訪問就可能會導(dǎo)致野指針[1].
Exception Type: SIGSEGV Exception Codes: SEGV_ACCERR at 0x12345678 Triggered by Thread: 1
簡單加個鎖就可以解決問題了:
@synchronized(self){ if(handler == nil) { hander = [[Handler alloc] init]; } } return handler;
0x3 多線程下對變量的存取
if (self.xxx) { [self.dict setObject:@"ah" forKey:self.xxx]; }
大家第一眼看到這樣的代碼,是不是會認(rèn)為是正確的?因為在設(shè)置key的時候已經(jīng)提前進(jìn)行了self.xxx為非nil的判斷,只有非nil得情況下才會執(zhí)行后續(xù)的指令。但是,如上代碼只有在單線程的前提下才是正確的。
假設(shè)我們將上述代碼目前執(zhí)行的線程為Thread A,當(dāng)我們執(zhí)行完if (self.xxx)
的語句之后,此時CPU將執(zhí)行權(quán)切換給了Thread B,而這個時候Thread B中調(diào)用了一句self.xxx = nil
。 使用局部變量可以解決這個問題
__strong id val = self.xxx; if (val) { [self.dict setObject:@"ah" forKey:val]; }
這樣,無論多少線程嘗試對self.xxx進(jìn)行修改,本質(zhì)上的val都會保持現(xiàn)有的狀態(tài),符合非nil的判斷。
0x4 dispatch_group 的崩潰
dispatch_group_enter 和 leave 必須是匹配的,不然就會crash . 在多資源下載的時候,往往需要使用多線程并發(fā)下載,全部下載完之后通知用戶。開始下載,dispatch_group_enter ,下載完成dispatch_group_leave 。 非常簡單的流程,但是當(dāng)代碼復(fù)雜到一定程度或者是使用了一些第三方庫的時候,就很大可能出問題。
dispatch_group_t serviceGroup = dispatch_group_create(); dispatch_group_notify(serviceGroup, dispatch_get_main_queue(), ^{ NSLog(@"Finish downloading :%@", downloadUrls); }); // t 是一個包含一堆字符串的數(shù)組 [downloadUrls enumerateObjectsUsingBlock:^(id _Nonnull obj, NSUInteger idx, BOOL * _Nonnull stop) { dispatch_group_enter(serviceGroup); SDWebImageCompletionWithFinishedBlock completion = ^(UIImage *image, NSError *error, SDImageCacheType cacheType, BOOL finished, NSURL *imageURL) { dispatch_group_leave(serviceGroup); NSLog(@"idx:%zd",idx); }; [[SDWebImageManager sharedManager] downloadImageWithURL:[NSURL URLWithString: downloadUrls[idx]] options:SDWebImageLowPriority progress:nil completed:completion]; }];
使用多線程進(jìn)行并發(fā)下載,直到所有圖片都下載完成(可以失敗)進(jìn)行回調(diào),其中圖片下載使用的是SDWebImage.發(fā)生崩潰的場景是:有10 張圖片,分開兩次下載(A & B)。其中在B組里面有一張圖片和A組下載的圖片重復(fù)了。假設(shè)A組下載對應(yīng)GroupA ,B組GroupB
下面截取SDWebImage源碼:
dispatch_barrier_sync(self.barrierQueue, ^{ SDWebImageDownloaderOperation *operation = self.URLOperations[url]; if (!operation) { operation = createCallback(); // ****注意這行**** self.URLOperations[url] = operation; __weak SDWebImageDownloaderOperation *woperation = operation; operation.completionBlock = ^{ SDWebImageDownloaderOperation *soperation = woperation; if (!soperation) return; if (self.URLOperations[url] == soperation) { [self.URLOperations removeObjectForKey:url]; }; }; } // ****注意這行**** id downloadOperationCancelToken = [operation addHandlersForProgress:progressBlock completed:completedBlock]; }
SDWebImage的下載器會根據(jù)URL做下載任務(wù)對應(yīng)NSOperation映射,相同的URL會映射到同一個未執(zhí)行的NSOperation。當(dāng)A組圖片下載完成后,相同的url 回調(diào)是 GroupB 而不是Group A。此時Group B的計數(shù)為1 。當(dāng)B 組圖片全部下載完后,結(jié)束計數(shù)為 5+1 。因為enter 的次數(shù)為5 ,leave 的次數(shù)為6 ,因此會崩潰!
0x5 最后一個持有者釋放后的崩潰
對象A被 manager 持有,在A中調(diào)用[Manager removeObjectA]
。A對象的retainCount -1
, 當(dāng)retainCount 等于零時,對象A已經(jīng)開始釋放了。在調(diào)用removeObjectA 后,緊接著調(diào)用[self doSomething]
,就會崩潰。
- (void)finishEditing { [Manager removeObject:self]; [self doSomething]; }
這種情況一般會發(fā)生在數(shù)組或者字典包含對象,而且是對象的最后持有者。當(dāng)在對象處理不好,就會有上面的崩潰。還有一種情況就是,當(dāng)數(shù)組或者字典里面的對象已經(jīng)被釋放了,當(dāng)遍歷數(shù)組或者取字典里面的值發(fā)生崩潰。這種情況,會讓人很崩潰,因為有時候堆棧是這樣的:
Thread 0 Crashed: 0 libobjc.A.dylib 0x00000001816ec160 _objc_release :16 (in libobjc.A.dylib) 1 libobjc.A.dylib 0x00000001816edae8 __ZN12_GLOBAL__N_119AutoreleasePoolPage3popEPv :508 (in libobjc.A.dylib) 2 CoreFoundation 0x0000000181f4c9fc __CFAutoreleasePoolPop :28 (in CoreFoundation) 3 CoreFoundation 0x0000000182022bc0 ___CFRunLoopRun :1636 (in CoreFoundation) 4 CoreFoundation 0x0000000181f4cc50 _CFRunLoopRunSpecific :384 (in CoreFoundation) 5 GraphicsServices 0x0000000183834088 _GSEventRunModal :180 (in GraphicsServices) 6 UIKit 0x0000000187236088 _UIApplicationMain :204 (in UIKit) 7 Tmall4iPhone 0x00000001000b7ae4 main main.m:50 (in Tmall4iPhone) 8 libdyld.dylib 0x0000000181aea8b8 _start :4 (in libdyld.dylib)
產(chǎn)生這種堆??赡艿膱鼍笆牵?/p>
釋放Dictionary的時候,某個值(value)因為被其他代碼提前釋放變成野指針, 此時再次被釋放觸發(fā)Crash. 如果可以在每個Dictionary釋放的時候, 把所有的key/value打出來, 如果某個key/value剛好被打出來之后, crash就發(fā)生了, 那么掛就掛在剛被打出來的key/value上.
0x6 對象的釋放線程要和它處理事情的線程一致
對象A在主線程監(jiān)聽Notification事件,如果這個對象被其它線程釋放了。此刻,如果對象A 正在執(zhí)行notification 相關(guān)的操作,再訪問對象相關(guān)資源就野指針了,發(fā)生crash.
0x7 performSelector:withObject:afterDelay:
調(diào)用此方法,如果不是在主線程,那么必須要確保當(dāng)前線程的ruuloop是存在的,performSelector_xxx_afterDelay 依賴runlopp才能執(zhí)行。另外使用performSelector:withObject:afterDelay:
和cancelPreviousPerformRequestsWithTarget
組合的時候要小心。
afterDelay會增加receiver的引用計數(shù),cancel則會對應(yīng)減一
如果在receiver的引用計數(shù)只剩下1 (僅為delay)時,調(diào)用cancel之后會立即銷毀receiver,后續(xù)再調(diào)用receiver的方法就會crash
__weak typeof(self) weakSelf = self; [NSObject cancelPreviousPerformRequestsWithTarget:self]; if (!weakSelf) { //NSLog(@"self被銷毀"); return; } [self doOther];
以上是“iOS中多線程的經(jīng)典崩潰示例”這篇文章的所有內(nèi)容,感謝各位的閱讀!相信大家都有了一定的了解,希望分享的內(nèi)容對大家有所幫助,如果還想學(xué)習(xí)更多知識,歡迎關(guān)注創(chuàng)新互聯(lián)網(wǎng)站建設(shè)公司行業(yè)資訊頻道!
另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)建站jinyejixie.com,海內(nèi)外云服務(wù)器15元起步,三天無理由+7*72小時售后在線,公司持有idc許可證,提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國服務(wù)器、虛擬主機(jī)、免備案服務(wù)器”等云主機(jī)租用服務(wù)以及企業(yè)上云的綜合解決方案,具有“安全穩(wěn)定、簡單易用、服務(wù)可用性高、性價比高”等特點與優(yōu)勢,專為企業(yè)上云打造定制,能夠滿足用戶豐富、多元化的應(yīng)用場景需求。
網(wǎng)站題目:iOS中多線程的經(jīng)典崩潰示例-創(chuàng)新互聯(lián)
路徑分享:http://jinyejixie.com/article28/depjcp.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供小程序開發(fā)、服務(wù)器托管、手機(jī)網(wǎng)站建設(shè)、微信公眾號、網(wǎng)站營銷、移動網(wǎng)站建設(shè)
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時需注明來源: 創(chuàng)新互聯(lián)
猜你還喜歡下面的內(nèi)容