Unlocking the Double Checked Locking
In my career of about 1 year in IT industry, I have faced almost all instances of double checked locking failing in case of singleton. Frankly, this is a good problem to have when you know what what is causing the problem and what is the solution... Well, until, your solutions start failing too. Here is my account on what can make singleton create multiple instances.
1) One can serialize a singleton just like any other object. But when you deserialize it, you will get a new instance of class every time because the reference to that object is null. There is a readResolve() method in dateFormat to get around this problem.
2) If your singleton class extends another class that supports cloning, your class also will be clonable.
SingletonObject clone = (SingletonObject) obj.clone();
In order to avoid this, add a clone method of your own in your singleton which throws an exception say cloneNotSupportedException().
3) There can be more than one instances of singleton if you use lazy initialization(neglecting synchroniztion). One should always use double checked locking along with a volatile boolean in order to avoid optimization done by compiler.
4) Multiple singltons might occur if someone subclasses your singleton. In this case if you have made constructor of your singleton protected, the sublclass might expose it making its constructor public. As instance of subclass is an instance of superclass, you will have multiple instances of singleton. To avoid this, always make constructor of singleton private.
5) When inside the constructor, a thread might take considerable amount of time to create an instance, by which time another thread might come, see a non-null instance and proceed with the half created instance. Another flag might come in handy here which you can set to true once the instance has been created. This boolean will be checked along with the null==instance condition.
Well... these are all I have come across so far. If you really don't want to get in this mess and simply don't care about the whole performance bit, simply synchronize getInstance() and you shall achieve what is intended.
1) One can serialize a singleton just like any other object. But when you deserialize it, you will get a new instance of class every time because the reference to that object is null. There is a readResolve() method in dateFormat to get around this problem.
2) If your singleton class extends another class that supports cloning, your class also will be clonable.
SingletonObject clone = (SingletonObject) obj.clone();
In order to avoid this, add a clone method of your own in your singleton which throws an exception say cloneNotSupportedException().
3) There can be more than one instances of singleton if you use lazy initialization(neglecting synchroniztion). One should always use double checked locking along with a volatile boolean in order to avoid optimization done by compiler.
4) Multiple singltons might occur if someone subclasses your singleton. In this case if you have made constructor of your singleton protected, the sublclass might expose it making its constructor public. As instance of subclass is an instance of superclass, you will have multiple instances of singleton. To avoid this, always make constructor of singleton private.
5) When inside the constructor, a thread might take considerable amount of time to create an instance, by which time another thread might come, see a non-null instance and proceed with the half created instance. Another flag might come in handy here which you can set to true once the instance has been created. This boolean will be checked along with the null==instance condition.
Well... these are all I have come across so far. If you really don't want to get in this mess and simply don't care about the whole performance bit, simply synchronize getInstance() and you shall achieve what is intended.
Labels: Tech
0 Comments:
Post a Comment
Subscribe to Post Comments [Atom]
<< Home