Surya - normally you'd also provide a private constructor. Otherwise, it's easy for anyone to create their own instance.
You'd also normally want to provide some public way to obtain a reference to the SINGLE reference. Right now it's private, and no other code references it. Maybe you intend to use SINGLE inside onlyOneInstance(), but that method returns a void, so it can't make the reference available to the outside world. To be honest, I have no idea what onlyOneInstance() might do, as shown.
Aside from those issues...
surya.raaj prakash wrote:Has anybody else here read the above singleton design and if so, what are your thoughts Regarding this design in mulithreaded environment?
Yes, this is simpler than a lazy-loaded singleton, so people don't discuss it as much. But a properly-coded eagerly-loaded singleton can be quite thread-safe, yes.
surya.raaj prakash wrote:will multiple different objects create or single object create by multiple threads?
Um, if you make a private constructor (the
only constructor), and if you provide a public method that returns the instance... then there should be only one instance, shared by all threads.
I'm going to skip all the usual anti-singleton rhetoric, as I expect someone will be along shortly to point you towards all that. I just wanted to address the specifics of your post.