Comparison
Double-checked lockingvsLazy initialisation
Double-checked locking
the code checks whether it is initialised, takes a lock, and checks again — and the second check is not redundant.
The idiom for lazily initialising a shared field without paying for a lock on every read: test, lock, test again, initialise. It is famous for having been subtly broken for years in several languages because without the right memory-model guarantee another thread can observe a partially constructed object. It is worth knowing as an interview answer about memory visibility, and worth avoiding in real code in favour of whatever your language's lazy holder is.
Full entry →Lazy initialisation
the field is null until the first person asks for it, and the first person asking pays for it.
Deferring the creation of something until it is first needed, so startup is cheap and unused things are never built. It moves cost from a predictable moment to an unpredictable one, which is fine for a cache and painful for a database connection opened during the first user request. Under concurrency it stops being a one-liner, which is what double-checked locking is about.
Full entry →