Shulou(Shulou.com)06/02 Report--

This article introduces the knowledge of "what are the classic crashes of multithreading in iOS". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

The collapse of the Block callback

In the MRC environment, use Block to set up the successfully downloaded image. When self is released, weakSelf becomes a wild pointer, and then it's tragic.

_ _ block ViewController * weakSelf = self

[self.imageView imageWithUrl:@ "" completedBlock: ^ (UIImage * image, NSError * error) {

NSLog (@ "% @", weakSelf.imageView.description)

}]

The collapse of Setter under multithreading

Getter & Setter write too much, in the case of a single thread, there is no problem. But in the case of multithreading, it may crash. Because [_ imageView release]; this code may be executed twice, oops!

UIKit is not a thread, so something that calls UIKit where it is not the main thread may be completely free from testing during the development phase. But once online, the crash system may be your crash log. Holy shit!

Solution: check whether the currently calling thread is the main thread by hook residing in setNeedsLayout,setNeedsDisplay,setNeedsDisplayInRect.

-(void) setImageView: (UIImageView *) imageView

{

If (! [_ imageView isEqual:imageView])

{

[_ imageView release]

_ imageView = [imageView retain]

}

}

More Setter-type crashes

Property attributes, the most written is nonatomic, in general, there is no problem!

@ interface ViewController ()

@ property (strong,nonatomic) NSMutableArray * array

@ end

Run the following code and you will see:

Malloc: error for object 0x7913d6d0: pointer being freed was not allocated

For (int I = 0; I < 100; iTunes +) {

Dispatch_async (dispatch_get_global_queue (DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^ {

Self.array = [[NSMutableArray alloc] init]

});

}

The reason is that the object has been relaese duplicated. Check the runtime source code

Solution: declare the property as atomic.

A more common example:

If (handler = = nil)

{

Hander = [[Handler alloc] init]

}

Return handler

If handler = = nil condition is satisfied when two threads access the if statement at the same time, both threads go to the next sentence to initialize the instance.

At this point, the A thread initializes and assigns values (we call it an in this example), and then moves on to other logic. At this point, thread B initializes and assigns values (we call it b in this example), and handler points to the object initialized by thread B. The instance an initialized by An is released because the reference count is reduced by 1 (to 0). But in the A thread, the code also tries to access the address where an is located, and the contents of this address become unpredictable because it is released, resulting in a wild pointer.

Another crucial point of the problem is that the reference count of an object does not increase during a call to a method of an object, so that if it is released, subsequent access to the object may result in a wild pointer [1].

Exception Type: SIGSEGV

Exception Codes: SEGV_ACCERR at 0x12345678

Triggered by Thread: 1

Simply adding a lock can solve the problem:

@ synchronized (self) {

If (handler = = nil)

{

Hander = [[Handler alloc] init]

}

}

Return handler

Access to variables under multithreading

If (self.xxx) {

[self.dict setObject:@ "ah" forKey:self.xxx]

}

When you first see such code, will you think it is correct? Because the judgment that self.xxx is non-nil has been made in advance when setting key, subsequent instructions will be executed only in the case of non-nil. However, the above code is correct only on the premise of a single thread.

Suppose that the thread currently executed by the above code is Thread A, and when we finish executing the statement of if (self.xxx), CPU switches the execution power to Thread B, and at this time a self.xxx = nil is called in Thread B. Using local variables can solve this problem.

_ _ strong id val = self.xxx

If (val) {

[self.dict setObject:@ "ah" forKey:val]

}

In this way, no matter how many threads try to modify the self.xxx, the essentially val will remain in its current state, in line with the non-nil judgment.

As a developer, it is very important to have a learning atmosphere and a communication circle. This is my iOS communication group: 519832104 whether you are rookie or Daniel, welcome to stay, share experiences, discuss technology, and share learning and growth together!

A copy of the interview questions collected by my friends is attached, which requires iOS to develop study materials and interview real questions. You can add iOS development advanced communication group and download it by yourself.

The collapse of dispatch_group

Dispatch_group_enter and leave must match, otherwise it will be crash. When downloading multiple resources, it is often necessary to use multiple threads to download concurrently, and notify the user after all the downloads are finished. Start downloading, dispatch_group_enter, downloading and completing dispatch_group_leave. It's a very simple process, but when the contemporary code is complex to a certain extent or uses some third-party libraries, it is likely to go wrong.

Dispatch_group_t serviceGroup = dispatch_group_create ()

Dispatch_group_notify (serviceGroup, dispatch_get_main_queue (), ^ {

NSLog (@ "Finish downloading:% @", downloadUrls)

});

/ / t is an array containing a bunch of strings

[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]

}]

Use multithreading to download concurrently until all images have been downloaded (can fail) for callback, where the image download uses SDWebImage. The scene of the crash is that there are 10 pictures and two downloads (A & B). Among them, there is a picture in Group B that is repeated with the picture downloaded by Group A. Suppose Group A downloads corresponding GroupA, Group B GroupB

The following intercepts the SDWebImage source code:

Dispatch_barrier_sync (self.barrierQueue, ^ {

SDWebImageDownloaderOperation * operation = self.URLOperations [url]

If (! operation) {

Operation = createCallback ()

/ / * pay attention to this line *

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]

}

}

}

/ / * pay attention to this line *

Id downloadOperationCancelToken = [operation addHandlersForProgress:progressBlock completed:completedBlock]

}

The downloader of SDWebImage will map the NSOperation to the download task based on URL, and the same URL will map to the same unexecuted NSOperation. When the group An image download is complete, the same url callback is GroupB rather than Group A. The count of Group B is 1. When all the pictures in group B are downloaded, the final count is 5: 1. Because the number of enter is 5 and the number of leave is 6, it crashes!

The collapse after the release of the last holder

Object An is held by manager and [Manager removeObjectA] is called in A. RetainCount-1 of object A, and when retainCount equals 00:00, object A has already begun to be released. After calling removeObjectA, followed by a call to [self doSomething], it crashes.

-(void) finishEditing

{

[Manager removeObject:self]

[self doSomething]

}

This usually happens when an array or dictionary contains an object and is the last holder of the object. When the object is not handled well, there will be a crash above. There is also a situation where when an object in an array or dictionary has been released, a crash occurs when traversing the array or fetching the value in the dictionary. This kind of situation can be very frustrating, because sometimes the stack looks like this:

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)

The possible scenarios for producing such a stack are:

When you release Dictionary, a value (value) becomes a wild pointer because it is released early by other code, and then it is released again to trigger Crash. If you can type out all the key/value when each Dictionary is released, if the crash occurs just after a key/value is typed out, then hang it on the key/value that has just been typed.

The release thread of the object should be the same as the thread on which it handles things

Object A listens for Notification events on the main thread if the object is released by another thread. At this point, if object An is performing a notification-related operation, then accessing the object-related resources will cause a wild pointer and crash.

PerformSelector:withObject:afterDelay:

To call this method, if it is not in the main thread, you must ensure that the ruuloop of the current thread exists and that the performSelector_xxx_afterDelay relies on runlopp to execute. Also be careful when combining performSelector:withObject:afterDelay: with cancelPreviousPerformRequestsWithTarget.

AfterDelay increases the reference count of receiver, while cancel subtracts one.

If the reference count of receiver is only 1 (delay only), receiver will be destroyed immediately after calling cancel, and the method that calls receiver later will crash.

_ _ weak typeof (self) weakSelf = self

[NSObject cancelPreviousPerformRequestsWithTarget:self]

If (! weakSelf)

{

/ / NSLog (@ "self destroyed")

Return

}

[self doOther]

This is the end of the content of "what are the classic crashes of multithreading in iOS"? thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.