Ist doppelt geprüftes Abschließen sicher?
In der Softwareentwicklung ist das doppelt überprüfte Sperren (auch bekannt als "doppelt überprüfte Sperroptimierung") ein Softwareentwurfsmuster, mit dem der Overhead beim Erfassen einer Sperre reduziert wird, indem das Sperrkriterium (der "Sperrhinweis") vor dem Erfassen der Sperre geprüft wird. Die Sperre wird nur dann aktiviert, wenn die Prüfung des Sperrkriteriums ergibt, dass eine Sperre erforderlich ist.

Das Muster kann in einigen Sprach-/Hardwarekombinationen unsicher sein. In manchen Fällen kann es als Anti-Pattern angesehen werden.

Es wird in der Regel verwendet, um den Sperr-Overhead bei der Implementierung von "Lazy Initialization" in einer Multi-Thread-Umgebung zu reduzieren, insbesondere als Teil des Singleton-Musters. Bei der "Lazy Initialization" wird die Initialisierung eines Wertes bis zum ersten Zugriff auf ihn vermieden.
Double Checked Locking kann in manchen Situationen unsicher sein und wird manchmal als Anti-Pattern angesehen. Es kann jedoch auf eine sichere Weise implementiert werden.
Is double checked locking safe?
In software engineering, double-checked locking (also known as "double-checked locking optimization"[1]) is a software design pattern used to reduce the overhead of acquiring a lock by testing the locking criterion (the "lock hint") before acquiring the lock. Locking occurs only if the locking criterion check indicates that locking is required.

The pattern, when implemented in some language/hardware combinations, can be unsafe. At times, it can be considered an anti-pattern.[2]

It is typically used to reduce locking overhead when implementing "lazy initialization" in a multi-threaded environment, especially as part of the Singleton pattern. Lazy initialization avoids initializing a value until the first time it is accessed.
Double checked locking can be unsafe in some situations and is sometimes considered an anti-pattern. However, it can be implemented in a safe way.