The better Java singleton pattern nowadays? [duplicate]

Answer 1

I was not aware that enums were the Java way to build singletons these days. But if you're going to do it that way, you may as well just use the enum directly. I don't see any good reason to encapsulate the singleton behind a bunch of static member methods; once you've done that, you may as well have written a static class with private static members to begin with.

Answer 2

The "better" singleton pattern is not to use one.

The approach that you describe, like all approaches that create the singleton via static initialization, is extremely hard to debug.

Instead, use dependency injection (with or without a framework such as Spring).

Answer 3

The problem I see with this approach is code duplication; if your singleton has a lot of methods, you end up writing them twice to make sure your delegation logic works. Look into the "initialization on demand holder idiom" for an alternative to your approach which is thread safe and doesn't need the enum hack.

Answer 4

The enum approach for Singletons was popularized by Joshua Bloch in his book Effective Java. Another good way is the lazy holder pattern, which is sort of similar to OP's idea. I think hiding the enum within a class like OP proposes will not add any performance or concurrency risks.

Singletons are still used a lot, although they are often hidden within the frameworks we use. Whether or not to use a Singleton depends on the situation, I don't agree that they should never ever be used. Singleton has gotten a bad name because of the horrible overuse in some poorly designed systems.

Answer 5

I like enums for a Singleton but the show stopper is when you need inheritance (as I do here). Enums cannot inherit. With dp4j a minimal Singleton looks like that:

@com.dp4j.Singleton //(lazy=false)
public class MySingleton extends Parent{}

dp4j will actually create this:

@Singleton
public class ApplicationSingleton extends Parent{

  @instance
  private static ApplicationSingleton instance = new ApplicationSingleton();

  private ApplicationSingleton(){}

  @getInstance
  public static ApplicationSingleton getInstance(){
     return instance;
  }

As you point out this solution is vulnerable to a 'Reflection attack'. On dp4j.com there's indeed a demonstration on how to unit test the Singleton using the Reflection API.

Answer 6

I need to thank you about this conversation, but I need to update the private constructor code as :

private ApplicationSingleton() {
    long currentTime = System.currentTimeMillis();
    System.out.println("Singleton instance is created: " + currentTime);
}

And here is the output:

Singleton instance is created: 1347981459285
Singleton instance is created: 1347981459285
Singleton instance is created: 1347981459285
applSingleton1=singlton.enums.ApplicationSingleton@12bc8f01,        
applSingleton2=singlton.enums.ApplicationSingleton@3ae34094,   
applSingleton3=singlton.enums.ApplicationSingleton@1da4d2c0

What should to mention:

1. Singleton instance was created several! times
2. All registry objects are different objects with its own data

because we force the private constructor to be public in c.setAccessible(true);

A value of true indicates that the reflected object should suppress Java language access checking when it is used. A value of false indicates that the reflected object should enforce Java language access checks.

therefore to test the singleton pattern thread-safety you shall use multithreading application