¿Por qué Apple recomienda usar dispatch_once para implementar el patrón singleton en ARC?

¿Cuál es la razón exacta para usar dispatch_once en el acceso de instancia compartida de un singleton en ARC?

+ (MyClass *)sharedInstance
{
    //  Static local predicate must be initialized to 0
    static MyClass *sharedInstance = nil;
    static dispatch_once_t onceToken = 0;
    dispatch_once(&onceToken, ^{
        sharedInstance = [[MyClass alloc] init];
        // Do any other initialisation stuff here
    });
    return sharedInstance;
}

¿No es una mala idea instanciar el singleton asincrónicamente en segundo plano? Quiero decir, ¿qué sucede si solicito esa instancia compartida y confío en ella de inmediato, pero dispatch_once toma hasta Navidad para crear mi objeto? No vuelve de inmediato, ¿verdad? Al menos ese parece ser el objetivo de Grand Central Dispatch.

Entonces, ¿por qué están haciendo esto?

dispatch_once()Es absolutamente sincrónico. No todos los métodos GCD hacen las cosas de forma asíncrona (en este caso, dispatch_sync()es síncrono). El uso de dispatch_once()reemplaza el siguiente modismo:

+ (MyClass *)sharedInstance {
    static MyClass *sharedInstance;
    @synchronized(self) {
        if (sharedInstance == nil) {
            sharedInstance = [[MyClass alloc] init];
        }
    }
    return sharedInstance;
}

El beneficio de dispatch_once()esto es que es más rápido. También es semánticamente más limpio, porque también lo protege de múltiples subprocesos haciendo alloc init de su SharedInstance, si todos lo intentan al mismo tiempo exacto. No permitirá que se creen dos instancias. La idea dispatch_once()es "realizar algo una vez y solo una vez", que es precisamente lo que estamos haciendo.

Porque solo se ejecutará una vez. Por lo tanto, si intenta acceder a él dos veces desde diferentes hilos, no causará ningún problema.

Mike Ash tiene una descripción completa en su publicación de blog Care and Feeding of Singletons .

No todos los bloques GCD se ejecutan de forma asincrónica.