Performance Optimization-finding and solving zombie objects

Memory leakage occurs when an object or variable is not released after it is used. What if we go through another extreme situation? This leads to the over release issue, so that the object is "zombie" and the object is called a zombies object. If an object has been released, or the caller does not have ownership of the object and releases it, it will lead to a transitional release and a zombie object.

Zombie objects may sound terrible and unfamiliar to many people. If you want to talk about the exception of exec_bad_access, you may not be unfamiliar. The application that tries to call the method of a zombie object will crash (the application jumps out directly) and throw an exception exec_bad_access.

Let's take a look at the code snippet of viewcontroller:

-(Void) tableview :( uitableview *) tableview didselectrowatindexpath :( nsindexpath *) indexpath {nsuinteger ROW = [indexpath row]; nsdictionary * rowdict = [self. listteams objectatindex: Row]; nsstring * rowvalue = [rowdict objectforkey: @ "name"]; nsstring * message = [[nsstring alloc] initwithformat: @ "you have selected the % @ Team. ", Rowvalue]; uialertview * Alert = [[uialertview alloc] initwithtitle: @ "select team" message: messagedelegate: selfcancelbuttontitle: @ "OK" Comment: Nil]; [alert release]; ① [Message release]; [alert show]; ② [tableview deselectrowatindexpath: indexpath animated: Yes];}

 

 

Check the simhei part of the program code. What problems do you find? Exec_bad_access exception is thrown in the running result. If the problem cannot be found, you can use the zombies Tracking template of the instruments tool. Select the zombies template for instruments and click the Profile button.

Click the "I" button in allocations to bring up the zombies template configuration in the target menu, and select record reference counts and enable nszombie detection in the launch configuration. The record reference counts shows the reference count, and the Enable nszombie detection is able to detect zombie objects.

In this way, when the program runs, if a zombie object is found, a dialog box will pop up. Click the "→" button, and the details of the zombie object will be displayed at the bottom of the screen.

 

The botnet object is of the uialertview type. The changes in the reference count from top to bottom are: Create, release, and botnet. Open the extended Details View, and enter the trace stack information on the right to our program code. The corresponding code is opened to locate the zombie object.

 

The above three highlighted codes will affect the object reference count, from which we can easily find problems. For the solution, in this example, You need to place the [alert show] statement in the warning box of line 2 of the code before the [alert release] statement. This is a botnet issue.