What is the difference between two implementation in java, which is the correct and why?
class Singleton
{
private static Singleton instance = new Singleton();
private Singleton()
{
System.out.println("Singleton(): Initializing Instance");
}
public static Singleton getInstance()
{
return instance;
}
}
Or
class Singleton
{
private static Singleton instance;
static
{
instance = new Singleton();
}
private Singleton()
{
System.out.println("Singleton(): Initializing Instance");
}
public static Singleton getInstance()
{
return instance;
}
}
First coming to your question,
AFAIK, both code snippets are same. I don't see any difference.
However, As other answers have suggested there are better ways to create Singleton implementation. But that would be bit off-topic to your question and internet (google) is your best friend to find it out.
No difference. In both cases you are eagerly creating an instance and by the time getInstance() is called, the instance is ready.
But if you are looking for a easy and good implementation of singleton,
Better use an enum to implement Singleton
public enum Singleton {
INSTANCE;
}
My answer bases on this article about singleton: http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
Your first example should always work but does not allow lazy init.
In a single threaded environment you could implement a singleton like in "my" first example.
In a multi-threaded environment with Java 1.5 and referenced mutable objects you could use "my" second example.
Useful stackoverflow answer/articles:
What is an efficient way to implement a singleton pattern in Java?
Implementing the singleton pattern in Java
Singleton class in java
Example 1:
class SingleSingleton {
private Helper helper = null;
public Helper getHelper() {
if (helper == null)
helper = new Helper();
return helper;
}
}
Example 2:
class MultiSingletonJDK5 {
private volatile Helper helper = null;
public Helper getHelper() {
if (helper == null) {
synchronized(this) {
if (helper == null)
helper = new Helper();
}
}
return helper;
}
}
I hope this helps. If not, give us some details or more background.
Both implementations are not correct, also static qualifier are not quite good practice at all :)
There are my suggestion of Singletns:
public final class LazySingleton {
private static volatile LazySingleton instance = null;
// private constructor
private LazySingleton() {
}
public static LazySingleton getInstance() {
if (instance == null) {
synchronized (LazySingleton.class) {
instance = new LazySingleton();
}
}
return instance;
}
}
public class EagerSingleton {
private static volatile EagerSingleton instance = null;
// private constructor
private EagerSingleton() {
}
public static EagerSingleton getInstance() {
if (instance == null) {
synchronized (EagerSingleton.class) {
// Double check
if (instance == null) {
instance = new EagerSingleton();
}
}
}
return instance;
}
}
Generally, Singleton design pattern concept is based on having only single instance of your class. This could be reached through two main aspects:
1) Having a private constructor for your class to prevent any outer class to call it and re-create the instance. This could be reached as the following:
private Singleton()
{
System.out.println("Singleton(): Initializing Instance");
}
2) Having a static method that allow you to retrieve the initialized instance or initialize it if it is not initialized yet as #Awfully Awesome mentioned in his answer:
public static Singleton newInstance()
{
if (singleton == null)
{
singleton = new Singleton();
}
return singleton;
}
Both the mentioned methods are not the right way of applying Singleton pattern.
Here's the right way. The Lazy-Instantiation way:
public class Singleton
{
private static Singleton singleton;
private Singleton()
{
}
public synchronized static Singleton getInstance()
{
if (singleton == null)
{
singleton = new Singleton();
}
return singleton;
}
}
The getInstance() method lazily instantiates Singleton object when its called the first time. So the Singleton object isn't present in the memory, till the moment its required.
Related
This is a job interview question.
Implement the singleton pattern with a twist. First, instead of
storing one instance, store two instances. And in every even call of
getInstance(), return the first instance and in every odd call of
getInstance(), return the second instance.
My implementation is as follows:
public final class Singleton implements Cloneable, Serializable {
private static final long serialVersionUID = 42L;
private static Singleton evenInstance;
private static Singleton oddInstance;
private static AtomicInteger counter = new AtomicInteger(1);
private Singleton() {
// Safeguard against reflection
if (evenInstance != null || oddInstance != null) {
throw new RuntimeException("Use getInstance() instead");
}
}
public static Singleton getInstance() {
boolean even = counter.getAndIncrement() % 2 == 0;
// Make thread safe
if (even && evenInstance == null) {
synchronized (Singleton.class) {
if (evenInstance == null) {
evenInstance = new Singleton();
}
}
} else if (!even && oddInstance == null) {
synchronized (Singleton.class) {
if (oddInstance == null) {
oddInstance = new Singleton();
}
}
}
return even ? evenInstance : oddInstance;
}
// Make singleton from deserializaion
protected Singleton readResolve() {
return getInstance();
}
#Override
protected Object clone() throws CloneNotSupportedException {
throw new CloneNotSupportedException("Use getInstance() instead");
}
}
Do you see a problem? The first call may enter getInstance and the thread get preempted. The second call may then enter getInstance but will get the oddInstance instead of the evenInstance.
Obviously, this can be prevented by making getInstance synchronized, but it's unnecessary. The synchronization is only required twice in the lifecycle of the singleton, not for every single getInstance call.
Ideas?
Most importantly, the evenInstance and oddInstance variables need to be declared volatile. See the famous "Double-Checked Locking is Broken" declaration: https://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
Also, you should really use different objects in the synchronization blocks for the even and odd instances so they can be constructed simultaneously.
Finally, the check in the Singleton constructor is broken and will throw an exception in the second call to getInstance()
Other than that it's fine, but it's better if you don't do the concurrency work yourself:
public final class Singleton implements Cloneable, Serializable {
private static AtomicInteger counter = new AtomicInteger(1);
public static Singleton getInstance() {
if (counter.getAndIncrement() % 2 == 0) {
return EvenHelper.instance;
} else {
return OddHelper.instance;
}
}
private static class EvenHelper {
//not initialized until the class is used in getInstance()
static Singleton instance = new Singleton();
}
private static class OddHelper {
//not initialized until the class is used in getInstance()
static Singleton instance = new Singleton();
}
}
You don't say the singleton must be lazily initialized, so I'll assume not...
You could be over-thinking it. Try this:
public final class Singleton implements Cloneable, Serializable {
private static Singleton[] instances = new Singleton[]{new Singleton(), new Singleton()};
private static AtomicInteger counter = new AtomicInteger();
private Singleton() {} // further protection not necessary
public static Singleton getInstance() {
return instances[counter.getAndIncrement() % 2];
}
// Make singleton from deserializaion
protected Singleton readResolve() {
return getInstance();
}
#Override
protected Object clone() throws CloneNotSupportedException {
throw new CloneNotSupportedException("Use getInstance() instead");
}
}
If you're worried about reflection attacks, just use an enum, which is bullet-proof, something like:
public final class Singleton implements Cloneable, Serializable {
private static AtomicInteger counter = new AtomicInteger();
private enum SingletonInstance implements Cloneable, Serializable {
ODD, EVEN;
private Singleton instance = new Singleton();
}
private Singleton() {} // further protection not necessary
public static Singleton getInstance() {
return SingletonInstance.values()[counter.getAndIncrement() % 2].instance;
}
// Make singleton from deserializaion
protected Singleton readResolve() {
return getInstance();
}
}
Do you see a problem? The first call may enter getInstance and the thread get preempted. The second call may then enter getInstance but will get the oddInstance instead of the evenInstance.
Obviously, this can be prevented by making getInstance synchronized, but it's unnecessary. The synchronization is only required twice in the lifecycle of the singleton, not for every single getInstance call.
If you really want to "fix" this "problem", your only option is to synchronize getInstance. But how would one really see this problem? What if the first thread is preempted right after getInstance?
In multithreading, the absolute order of events is not completely deterministic. So you always have the risk that actions seem to be out-of-order.
btw: The against the "reflection attack" has a serious flaw! It prevents the construction of evenInstance! I guess you should change || to &&. But that still doesn't give you any guarantees, because the "reflection attack" could be between the first and second call. You have to preconstruct both instances at class loading time to be 99% sure.
And if you're worried about it, you should definitely implement neither Cloneable nor Serializable!
How does Singleton behave when two threads call the "getInstance()" at the same time? What are the best practices to protect it?
This is only an issue at all if you use lazy initialization on the singleton. If you use eager initialization then the JVM guarantees to sort it all out for you.
For lazy initialization you need to either synchronize (although you can make it volatile and use double-check locking to avoid synchronized blocks all the time) or embed it within an inner class where it is not lazy initialized.
peter.petrov's answer now covers most of the options well, there is one final approach to thread safe lazy initialization though that is not covered and it is probably the neatest one.
public class Singleton {
// Prevent anyone else creating me as I'm a singleton
private Singleton() {
}
// Hold the reference to the singleton instance inside a static inner class
private static class SingletonHolder {
static Singleton instance = new Singleton();
}
// Return the reference from inside the inner class
public static Singleton getInstance() {
return SingletonHolder.instance;
}
}
Java does lazy loading on classes, they are only loaded when first accessed. This applies to inner classes too...
Firstly, two threads can't call the method at the "same time" - one will be deemed to call it first... called a "race condition".
Next, any properly implemented singleton will handle a race condition cleanly. IMHO, this is the cleanest way to implement a thread-safe singleton without synchronization:
public class MySingleton {
private static class Holder {
static final MySingleton INSTANCE = new MySingleton ();
}
public static MySingleton getInstance() {
return Holder.INSTANCE;
}
// rest of class omitted
}
This is called the initialization-on-demand holder idiom.
1) If you want lazy init, I think a good practice is to synchronize the getInstance body on a private static final Object instance which is member of the same class (you may name it LOCK e.g.).
2) If you don't need lazy init you can just instantiate your singleton instance at class load time. Then there's no need of any synchronization in getInstance.
Sample of 1) without using DCL (double-checked locking)
Note 1: This one avoids the complexity of using DCL by paying some extra price with respect to performance.
Note 2: This version is OK on JDK < 5 as well as on JDK >= 5.
public class Singleton {
private static final Object LOCK = new Object();
private static Singleton instance = null;
public static Singleton getInstance(){
synchronized(LOCK){
if (instance == null){
instance = new Singleton();
}
return instance;
}
}
private Singleton(){
// code to init this
}
}
Sample of 1) using DCL
Note 1: This is OK on JDK >= 5 but not on JDK < 5.
Note 2: Note the volatile keyword used, this is important.
public class Singleton {
private static final Object LOCK = new Object();
private static volatile Singleton instance = null;
public static Singleton getInstance(){
if (instance == null){
synchronized(LOCK){
if (instance == null){
instance = new Singleton();
}
}
}
return instance;
}
private Singleton(){
// code to init this
}
}
Sample of 2)
Note 1: This is the most simple version.
Note 2: Works on any JDK version.
public class Singleton {
private static Singleton instance = new Singleton();
public static Singleton getInstance(){
return instance;
}
private Singleton(){
// code to init this
}
}
References:
1) Older JDK versions (JDK < 5)
http://www.javaworld.com/article/2074979/java-concurrency/double-checked-locking--clever--but-broken.html
2) More recent updates on DCL
http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
public class Singleton{
private static class Holder {
static final Singleton INSTANCE = new Singleton();
}
public static Singleton getInstance() {
return Holder.INSTANCE;
}
}
When the getInstance method is invoked for the first time, it reads Holder.INSTANCE for the first time, causing the Holder class to get initialized. The beauty of this idiom is that the getInstance method is not synchronized and performs only a field access.This is called lazy initialization. You might think that Holder class should also be loaded by the class loader when Singleton class is loaded because Holder class is static. Loading a top-level class does not automatically load any nested types within,Unless there's some other initialization that occurs during the top-level initialization, like if your top-level class has a static field that needs to be initialized with a reference to an instance of the nested class.
Synchronize access of getInstance.
Class TestSingleton {
private static volatile TestSingleton singletonObj = null;
private TestSingleton (){ // make constructor private
}
public static getInstance(){
TestSingleton obj = singletonObj ;
if(obj == null) {
synchronized(lock) { // while we were waiting for the lock, another
obj = instance; // thread may have instantiated the object
if(obj == null) {
obj = new TestSingleton();
instance = obj ;
}
}
}
public doSomeWork(){ // implementation
}
}
I have come across another article in stackexchange on various ways to implement java singleton. One of the ways shown is the following example. It has been voted very low. Wanted to understand why.
What is an efficient way to implement a singleton pattern in Java?
public class Singleton {
private static Singleton instance = null;
static {
instance = new Singleton();
// do some of your instantiation stuff here
}
private Singleton() {
if(instance!=null) {
throw new ErrorYouWant("Singleton double-instantiation, should never happen!");
}
}
public static getSingleton() {
return instance;
}
}
As #Craig says in the comments:
Not true. static variables are initialized along with static blocks when the class is loaded. No need to split the declaration.
Essentially it was down voted because it was misinformation, a lot of what he was saying was just plain not true. Specifically, initializing a static variable with a static method will occur when the class is loaded, while the author claimed that this was not the case.
His argument also doesn't really make sense, "data insertion" could just be done within the constructor.
With that said, the above code will work fine, it's just an odd way of doing it, and arguably the least stylistic.
following solution make sure it's thread safe
public class Singleton {
// Private constructor prevents instantiation from other classes
private Singleton() { }
/**
* SingletonHolder is loaded on the first execution of Singleton.getInstance()
* or the first access to SingletonHolder.INSTANCE, not before.
*/
private static class SingletonHolder {
public static final Singleton INSTANCE = new Singleton();
}
public static Singleton getInstance() {
return SingletonHolder.INSTANCE;
}
}
This is not a good way to implement it.
As static variables are initialized at JVM load time, just make the singleton final:
public final class Singleton
{
private static final Singleton INSTANCE = new Singleton();
private Singleton()
{
// build it
}
public static Singleton getInstance()
{
return INSTANCE;
}
}
I have been having a hard time understanding how to use a singleton to share a common variable. I am trying to make a blackberry app which has two entry points which need to share a common variable, iconCount. I have been advised to use a singleton with the RunTimeStore API by someone on a forum. Googling around eventually leads to:
http://docs.blackberry.com/en/developers/deliverables/17952/CS_creating_a_singleton_by_using_rutnime_store_1554335_11.jsp
I have been a few pages deep in Google but I still can`t understand what this does and how to implement it. My current understanding is that a singleton will create a "global variable" somehow through the code:
class MySingleton {
private static MySingleton _instance;
private static final long GUID = 0xab4dd61c5d004c18L;
// constructor
MySingleton() {}
public static MySingleton getInstance() {
if (_instance == null) {
_instance = (MySingleton)RuntimeStore.getRuntimeStore().get(GUID);
if (_instance == null) {
MySingleton singleton = new MySingleton();
RuntimeStore.getRuntimeStore().put(GUID, singleton);
_instance = singleton;
}
}
return _instance;
}
}
And another question would be how would I create a variable from this singleton? I need to declare variable iconCount = 0 at the beginning and then be able to use it. Would declaring it be something like
Integer iconCount = (Integer) RuntimeStore.getInstance();
? This is very new to me as I have just started Java so if anyone could explain this keeping in mind you're communicating with a novice I would be very grateful. Thanks in advance!
You would call
MySingleton.getInstance()
to get the instance in your app. The point is that getInstance is controlling access to the underlying object.
Also, you should make your constructor private, so it's only accessible in that file.
To define a property on you singleton class, just declare a non-static property. Each instance of the class will have its own copy, but you are controlling the creation of the objects, so their should only ever be 1 (per JVM). So
class MySingleton {
private static MySingleton _instance;
private static final long GUID = 0xab4dd61c5d004c18L;
private Integer iconCount; // non-static method, add a public getIconCount below
...
}
and then you can access it via
MySingleton.getInstance().getIconCount();
They mean please make sure that user initializing MySingleton class just onetime so you will not have problem with multiple instances and initialize two count in the same time. I mean from multiple instance something like below:
Mysingleton single = new Mysingleton();
Mysingleton single2 = new Mysingleton();
Because both initilaization can have diffetent count. You need something like this:
public class IconManager {
private static iconManager _instance;
private static final long GUID = 0xab4dd61c5d004c18L;
private static int count = 0;
// constructor
IconManager() {
}
public static IconManager getInstance() {
if (_instance == null) {
_instance = (IconManager) RuntimeStore.getRuntimeStore().get(GUID);
if (_instance == null) {
IconManager singleton = new IconManager();
RuntimeStore.getRuntimeStore().put(GUID, singleton);
_instance = singleton;
}
}
return _instance;
}
public static int getCount() {
return count;
}
public static void setCount(int count) {
this.count = count;
}
}
and after you can create an instance for the class:
public static void main(String[] args){
IconManager iconManager = IconManager.getInstance();
iconManager.setCount(iconmanager.getCount() + 1);
}
So application will do first validation, if there is already an instance it will update existing one, if not than it will create new one.
You can't cast your MySingleton class to Integer.
And in your example you don't use your singleton but RuntimeStore !
You can use an integer field of your class Singleton, initalized to 0 in the constructor of your singleton (private constructor) and get it by doing :
MySingleton.getInstance().getIntegerField()
here is a detailled description of the singleton pattern :
http://en.wikipedia.org/wiki/Singleton_pattern
I think you misunderstand the use of the singleton. the singleton is not injected in your RuntimeStore, it is a classic java object. The only subtile think to know about a singleton is that its constructor is private and the class MySingleton can have only one instance which is always returned when your singleton.getInstance() is called
Is it possible to have a singleton in a factory method? I have many domains using the factory method. How do I work around with this. Please help me with an example.
In this example, I believe you would want to synchronize your getInstance() method to ensure two threads do not simultaneously enter it. Otherwise two threads can end up inside the block where the singleton is instantiated which is very problematic. The only issue with this solution is you pay a premium for the synchronization of the method every time getInstance() is called.
Example:
public static synchronized Singleton getInstance()
{
// since whole method is synchronized only 1 thread can
// enter the following block ensuring only one instance
// is ever created. however we pay a synchronization
// penalty every time this method is called.
if(mInstance==null) {
mInstance=new Singleton();
}
return mInstance;
}
Alternatively you could also switch to use eager initialization of the singleton instance rather than lazy initialization if initializing is cheap which guarantees concurrency as well as not paying a synchronized penalty for invoking the getInstance() method.
Example:
// no synchronization penalty, but penalty for eager init
private static Singleton mInstance = new Singleton();
public static Singleton getInstance()
{
return mInstance;
}
The most optimized approach is to use double-checked locking, something you need Java 1.5 or newer to use reliably due to differing implementations of the volatile keyword in 1.4 or older JVMs (please refer to "Head First Design Patterns" chapter 5 p.182 published by O'Reilly Media, Inc. -- that is where I first read about this.)
Example:
private volatile static Singleton mInstance;
private Singleton(){}
public static Singleton getInstance()
{
if(mInstance==null) {
synchronized (Singleton.class) {
// only pay synchronization penalty once
if(mInstance==null){
mInstance=new Singleton();
}
}
}
return mInstance;
}
"...create an interface for objects that create instances of the Singleton class. This is essentially a combination of the Abstract Factory, Factory Method and Functor patterns in the GoF book."
/**
* An interface defining objects that can create Singleton
* instances.
*/
public interface SingletonFactoryFunctor {
/**
* #return An instance of the Singleton.
*/
public Singleton makeInstance();
}
You should call your Singleton getInstance() method from the factory method. The getInstance() logic should handle the details of returning the one instance of the Singleton.
Singleton you can implement like:
public class Singleton {
private static Singleton mInstance;
private Singleton(){}
public static Singleton getInstance()
{
if(mInstance==null){
mInstance=new Singleton();
}
return mInstance;
}
}
This class you can return in every Factory methode you want, like mepcotterell described before.
This example is not a formal Factory Pattern (GoF) but is still helpful if you use it like a Static Factory Method
abstract class Product {}
class ConcreteProduct extends Product{}
class ProductSupportFactory {
private static ProductSupportFactory instance = null;
private ConcreteProduct product = null;
static {
instance = new ProductSupportFactory();
}
private ProductSupportFactory() {
product = new ConcreteProduct(); //object initialization
}
public static ProductSupportFactory getInstance(){
return instance;
}
public ConcreteProduct getProduct() {
return product;
}
public void setProduct(ConcreteProduct product) {
this.product = product;
}
}
public class ProductConsumer {
public static void main(String args[]){ //client
ConcreteProduct uniqueInstance = ProductSupportFactory.getInstance().getProduct();
ConcreteProduct sharedInstance = ProductSupportFactory.getInstance().getProduct(); //same object hash
}
}