Today in my interview one interviewer asked me to write a Singleton class. And i gave my answer as
public class Singleton {
private static Singleton ref;
private Singleton() {
}
public static Singleton getInstance() {
if (ref == null) {
ref = new Singleton();
}
return ref;
}
}
suddenly he told me this is old way of writing the class. Can any one please help me why he told like that.
The first thing which comes to my mind when creating a singleton is enum. I generally use enum to implement singleton:
enum Singleton {
INSTANCE;
}
One benefit you get with using enum is with Serialization.
With singleton class, you would have to make sure that serialization and deserialization doesn't create a new instance by implementing the readResolve() method, while this is not the case with enum.
Using class you should create the singleton like this:
public final class Singleton implements Serializable {
// For lazy-laoding (if only you want)
private static class SingletonHolder {
private static final Singleton INSTANCE = new Singleton();
}
private Singleton() {
if (SingletonHolder.INSTANCE != null) {
// throw Some Exception
}
}
public static Singleton getInstance() {
return SingletonHolder.INSTANCE;
}
// To avoid deserialization create new instance
@SuppressWarnings("unused")
private Singleton readResolve() {
return SingletonHolder.INSTANCE;
}
}
Latest Standard Solutions:
Core java with Managed Beans / CDI
@ApplicationScoped
public class MySingleton { ... }
EJB Lite (JEE6)
@Singleton
public class MySingleton { ... }
Prior Recommendation (from 'Effective Java 2'):
Use an enum, with a single bogus enumeration constant e.g. INSTANCE. Data fields and methods can be either static or non-static (instance) - the two behave equivalently, since there's only one instance
Advantages:
Disadvantages (compared with above Standard Solutions):
You can do
public enum Singleton {
INSTANCE;
}
and for a utility class which has no instances
public enum Utility {
;
public static void method();
}
As others have already pointed out, the enum pattern is now widely considered a better approach to the Singleton vs. the old-school method, but I just wanted to point out a drawback.
We had a Singleton in the form of:
public enum Foo {
INSTANCE;
}
that had been around for awhile, working just fine. Then during a code review, we saw this:
public enum Foo {
INSTANCE,
ANOTHER;
}
After we smacked him across the face with a wet mackerel, the coder in question had seen the error of his ways, and a larger than small amount of code had to be backed out and/or rewritten. Yes, we caught it before it went out into production, but work had to be done to erase it.
I feel that this a weakness of this type of Singleton (albeit small and perhaps rare) vs. the old-school way. Yes, you can break any pattern by implementing it wrong, but it seems a whole heck of a lot easier for a coder to break an enum Singelton than a well-formed old-school Singleton.
EDIT:
For completeness, here's an enum Singleton that guards against additional values getting added later:
public enum Foo
{
INSTANCE;
// adding another type here will cause a runtime
static
{
if (Foo.values().length != 1)
{
throw new IllegalStateException("Not a Singleton.");
}
}
}
This is because your solution is not threadsafe.
The modern way is to tie the instance to an enum value:
enum Singleton {
INSTANCE;
}
If you want to use lazy init of the instance then you can use the ClassLoader to guarantee thread safety:
public class Singleton {
private Singleton() { }
private static class SingletonHolder {
public static final Singleton INSTANCE = new Singleton();
}
public static Singleton getInstance() {
return SingletonHolder.INSTANCE;
}
}
More information on Wikipedia
He's probably look for this answer:
public class Singleton
{
private static Singleton ref;
static
{
ref = new Singleton();
}
private Singleton()
{
}
public static Singleton getInstance()
{
return ref;
}
}
Notice the static block. This approach is probably heavy since the instance is created upon class loading.
The Singleton I'd write would look like this:
@Service
class PersonService {
// implementation here
}
But I also like the enum ideas. In reality, I never write (nor need) a Singleton other than one like the one above.
Why can't you do just
public class SingletonSandBox {
private static SingletonSandBox instance = new SingletonSandBox();
private SingletonSandBox(){
}
public static SingletonSandBox getInstance(){
return instance;
}
}
and test
public static void main(String[] args) {
SingletonSandBox sss1 = SingletonSandBox.getInstance();
SingletonSandBox sss2 = SingletonSandBox.getInstance();
System.out.println(sss1 == sss2);
}
As I know this is thread-safe and shorter than using static block. Again static field declaration is read earlier comparing to static block by the runtime.
Some times We might have to Create one instance of a subclass only Like Java Toolkit class. Example 1: Creating one instance of a subclass only will be elaborating out it. Please Refer: Singleton Design Patter in Java
From What is an efficient way to implement a singleton pattern in Java?
Use an enum:
public enum Foo
{
INSTANCE;
}
Joshua Bloch explained this approach in his book 'Effective Java'
Also check out The better Java singleton pattern nowadays?
A thread safe version of the OPs initial approach, plus no one else dared to suggest a synchronized statement.
final class Singleton
{
private static Object lock = new Object();
private static volatile Singleton instance = null;
private Singleton() { }
public static Singleton getInstance()
{
if(instance == null)
{
synchronized(lock)
{
if(instance == null)
{
instance = new Singleton();
}
}
}
return instance;
}
}
This singleton implementation is called,
lazy initialization
But the problem is this implementation is not a thread-safe one.
Here, you can find the best thread-safe implementation.
There are few other popular Singleton implementations as well. One is,
Eager initialization
final class EagerIntializedSingleton {
private static final EagerIntializedSingleton instance = new EagerIntializedSingleton();
private EagerIntializedSingleton (){}
private static EagerIntializedSingleton getInsance() {
return instance;
}
}
But here, the instance of the singleton class is created at the time of class loading. (This is the default singleton class which is created by the IntelliJ IDE)
The next popular implementation is,
Static block initialization
private static StaticBlockSingleton instance;
private StaticBlockSingleton(){}
static {
try {
instance = new StaticBlockSingleton();
catch(Exception e) {
.............
}
}
This implementation is similar to eager initialization, except the instance of the class is created in the static block that provides the option for "exception handling". Both eager initialization and static block initialization creates the instance even before it's being used and that is not the best practice to use.
It could be because it does not use "double-checked-locking" (as others have said) or it could also be because it is apparently possible to invoke a private constructor using reflection (if the security policy allows it).
To invoke a constructor with no parameters pass an empty array.
package org.example;
public class Singleton {
private static final Object LOCK = new Object();
private static final Singleton SINGLETON = new Singleton();
private static volatile boolean init = false; // 'volatile' to prevent threads from caching state locally (prevent optimizing)
private Singleton() {
synchronized (LOCK) {
if( init == true) {
throw new RuntimeException("This is a singleton class!");
}
init=true;
}
}
public static Singleton obtainClassInstance() {
return SINGLETON;
}
}
package org.example;
import java.lang.reflect.Constructor;
import java.lang.reflect.InvocationTargetException;
public class SimpleSingletonTester {
/**
* @param args
* @throws NoSuchMethodException
* @throws SecurityException
* @throws InvocationTargetException
* @throws IllegalAccessException
* @throws InstantiationException
* @throws IllegalArgumentException
*/
public static void main(String[] args) throws SecurityException, NoSuchMethodException,
IllegalArgumentException, InstantiationException, IllegalAccessException, InvocationTargetException
{
Class[] parameterTypes = {};
Object[] initargs = {};
Constructor<Singleton> constructor = Singleton.class.getDeclaredConstructor(parameterTypes);
System.out.println( constructor.isAccessible() );
constructor.setAccessible(true);
System.out.println( constructor.isAccessible() );
System.out.println( constructor.newInstance(initargs) );
System.out.println( constructor.newInstance(initargs) );
}
}
