Granny's Programming Pearls
"inside of every large program is a small program struggling to get out"
JavaRanch.com/granny.jsp
Win a copy of The Journey To Enterprise Agility this week in the Agile and Other Processes forum! And see the welcome thread for 20% off.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Jeanne Boyarsky
  • Liutauras Vilda
  • Campbell Ritchie
  • Tim Cooke
  • Bear Bibeault
Sheriffs:
  • Paul Clapham
  • Junilu Lacar
  • Knute Snortum
Saloon Keepers:
  • Ron McLeod
  • Ganesh Patekar
  • Tim Moores
  • Pete Letkeman
  • Stephan van Hulst
Bartenders:
  • Carey Brown
  • Tim Holloway
  • Joe Ess

Double Checked Locking  RSS feed

 
Ranch Hand
Posts: 30
4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi, All,

I'm thinking out loud here, and hopefully no one is offended by my comments.

I'm studying for the OCP with the Boyarsky/Selikoff book, and overall I find it and excellent resource.  I'm also reading other books in parallel.  In Chapter 2 of Boyarsky/Selikoff they are talking about the Singleton pattern, and on p81 in a "Real World Scenario" they mention the double ckecked locking mechanism for lazy initialization (and do use the volatile keyword).  The book specifically states that "The solution is to use double-checked locking, a design pattern ......".    However, Java Concurrency in Practice (another great resource) states that double checked locking is an outdated pattern for lazy initialization (even if it would work properly with the volatile keyword), and that a better mechanism for lazy initialization would be the "lazy initialization holder class idiom".  In fact, JCP actually lists double ckecked locking as one of the "bugs" that FindBugs looks for when analyzing code for bug patterns.

So, any thoughts?  I understand that this topic is beyond the scope of the exam, but I'm just curious what the experts think about this.  Why talk about double checked locking when there is a better pattern out there?  Or maybe it's not better and JCP is wrong? 

Thanks
 
author & internet detective
Marshal
Posts: 38504
653
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Elena,
Excellent topic. I've added it to the Threads forum since this is about real life programming.

The book covers simpler patterns for singletons because that's what you'd see on the exam. (If you see anything; questions about singleton are pretty rare on the exam.). In fact, double checked locking isn't on the exam either; we listed that as a real life scenario. We wanted to show the concept of synchronization without getting too complicated. Also, we haven't covered inner classes yet in chapter 2 so it is awkward to bring them up as an aside.

Personally, I'm not sure which pattern is better as I rarely need lazy instantiation where I use singletons in my projects.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!