2

If I implement a Singleton either through holder idiom or double checked locking, but instead of calling 'getInstance()', use reflection to instantiate it, and then call 'getInstance()' on it, this would create two instances, breaking the pattern.

So I add a static 'counter' member to the class, increment it in the class's private constructor, and throw an exception if it crosses '1'. But in that case, if I first instantiate through reflection, nobody else would be able to call 'getInstance()' without throwing an Exception.

So how do I lazy load a Singleton yet prevent it from this attack? (I'm aware of 'Enum' pattern, but some feel that it's actually a hack. Check comments on the accepted answer of this: is this Singleton resistant to both Serialization and Reflection Attacks? and btw, my question is different).

EDIT: I think it's possible to prevent it in case of DCL, by using the static counter field, class-based synchronized constructor and assigning 'this' to the static member. However, not sure how to prevent it in case of holder idiom.

Community
  • 1
  • 1
shrini1000
  • 7,038
  • 12
  • 59
  • 99
  • 1
    How is having an enum which clearly states you have only one instance a hack? It is simpler and would solve your problem to some degree. Perhaps its time to give in to the obvious answer. ;) BTW: You can create new enum instances with the Unsafe class. – Peter Lawrey Apr 13 '12 at 09:30
  • Well, I have nothing personal against enum based Singleton, but not everybody agrees that it's the right way, so wanted to explore. :) Btw, thx for the Unsafe ref., didn't know you can create new enums through it. +1 for that. – shrini1000 Apr 13 '12 at 09:34
  • 3
    Sufficiently privileged code can do anything... you can't prevent an attack by hardening your own code, only by taking away privileges from the untrusted code. – CurtainDog Apr 13 '12 at 10:02

1 Answers1

0

Personally I stick with Enums, but there is also the Initialization on Demand Holder (IODH) idiom 

static class SingletonHolder {
  static Singleton instance = new Singleton();    
}

public static Singleton getInstance() {
  return SingletonHolder.instance;
}

This appears in Effective Java (item 48), but I first heard of it from a post by crazy bob

http://blog.crazybob.org/2007/01/lazy-loading-singletons.html

See http://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html#dcl for lots of interesting discussion.

henry
  • 5,923
  • 29
  • 46
  • how will this prevent constructor-based reflection attack to create multiple objects of that Singleton? (btw, I meant the same approach when I mentioned 'holder idiom' in my question). – shrini1000 Apr 13 '12 at 09:45