Ios q & A series-Thoughts on iOS Standalone

========================================================== =============================== Original blog, reprinted please declare the source of Electronic coffee (original id blue rock) ========================================================== ================================

Recently, I wrote a piece of Single-profit code, as shown below.

# Import "wqplaysound. H "# define dispose_interval 3 @ implementation wqplaysoundstatic wqplaysound * instance = nil; static nsstring * Lock = @" "; + (wqplaysound *) protected wqplaysound {// synchronization prevents multi-thread access, here we would like to use instance as the lock object, but when instance is nil, it cannot be used as the Lock Object @ synchronized (LOCK) {If (! Instance) {instance = [[wqplaysound alloc] init] ;}} return instance ;}

Question 1: Do I need release for a single benefit?

No class shoshould need to retain a pointer to a singleton class. singleton class itself keeps a pointer to its instance. basically, when the user wants to use a Singleton, they will request it through a class method (by Convention often startingshared). This method will check if the Singleton has been initialized. if not, it will perform the initialization. if there is already an existing instance in memory, it will just return it. usually, a singleton object will live in memory for the life of the application.

The life cycle of a single profit is the same as that of appdelegate, so no release is required.

Question 2: Does the lock synchronization Lock Object of @ synchronized (LOCK) {...} still work if it is null?

Nil value used as mutex for @synchronized() (no synchronization will occur)

This is what xcode prompts me, So nil cannot be used. We can use an empty string @ "" to lock it.

Modify ----

Just now @ dolphinorca raised a question about my code. I tested it, but it was a misunderstanding. I would like to express my gratitude to dolphinorca.

Dolphinorca proposes to replace @ synchronized (LOCK) with @ synchronized (Self) for easier synchronization. At the time, I thought this was not acceptable,Because at @ synchronized (Self), self is not init, so self is nil, and synchronized (NiL) is invalid.

Later, I did another experiment to prove that my point of view was wrong.

Create Singleton

@ Implementation singletonstatic Singleton * instance = nil; static int I = 0; + (Singleton *) share {nslog (@ "SELF: % @ ---- I ++: % d ", self, I ++); @ synchronized (Instance) {// note that this time the instance is not self if (instance = nil) {If (I)> 1) {// I> 1 is for the first two threads to stay here for two seconds. Let the third thread first alloc and then alloc [nsthread sleepfortimeinterval: 2];} instance = [[Singleton alloc] init] ;}} return instance ;}

Start three threads in another file to obtain the single benefit, and then print it to see if the three single benefits are the same.

-(Void) viewdidload {[Super viewdidload]; // start three threads to call [nsthread detachnewthreadselector: @ selector (getsingleton) totarget: Self withobject: Nil]; [nsthread detachnewthreadselector: @ selector (getsingleton) totarget: Self withobject: Nil]; [nsthread failed: @ selector (getsingleton) totarget: Self withobject: Nil];}-(void) getsingleton {Singleton * s = [Singleton share]; nslog (@ "signle: % @", S );}

The result is as follows:

2012-11-06 17:21:46.933 SingletonDemo[811:3c07] self:Singleton----i++:02012-11-06 17:21:46.934 SingletonDemo[811:4303] self:Singleton----i++:12012-11-06 17:21:46.934 SingletonDemo[811:4603] self:Singleton----i++:22012-11-06 17:21:48.948 SingletonDemo[811:4603] signle:<Singleton: 0x744a5e0> //<<<<--------2012-11-06 17:21:48.948 SingletonDemo[811:4303] signle:<Singleton: 0x91174a0>2012-11-06 17:21:48.948 SingletonDemo[811:3c07] signle:<Singleton: 0x714b6e0>

We can see that the output singleton object is three different objects, which is my original idea.

On the line surface, I will replace the synchronized lock with self. The rest will remain unchanged and re-run the lock,

 @synchronized(self)

Output result:

17:41:32. 863 singletondemo [866: 4603] self: Singleton ---- I ++: 1 // self is a singleton class 17:41:32. 863 singletondemo [866: 3c07] self: Singleton ---- I ++: 02012-11-06 17:41:32. 863 singletondemo [866: 4103] self: Singleton ---- I ++: 22012-11-06 17:41:34. 879 singletondemo [866: 4603] signle: <singleton: 0x750e120> 17:41:34. 879 singletondemo [866: 3c07] signle: <singleton: 0x750e120> 17:41:34. 879 singletondemo [866: 4103] signle: <singleton: 0x750e120>

We can see that the benefits are the same object.

Later I thought that here self is a class lock, so there is no nil problem.

Concerning thread synchronization, I will continue to study it in the future blog