How do you create and later access an application level resource?

How do you create and later access an application level resource? - java

Edit: I am trying to create a shared database connection pool for all sessions of a web application. A different post said the best way to create a servlet context object was by having the init listener create it. I am however unclear on how to make this object available for use by my servlet.

Another way you could do this is use static initialization:
public class SomeClass {
private static final Object[] CONTENT;
static {
CONTENT = new Object[SomeOtherClass.getContentSize()]; // To show you can access runtime variables
}
}
This will initialize the CONTENT array once the class is loaded using the ClassLoader.

One solution is using a private holder class:
public class SomeClass {
private static class ResourceHolder {
private static final Resource INSTANCE = new Resource();
}
public static Resource getInstance() {
return ResourceHolder.INSTANCE;
}
}
the instance will be initialized when SomeClass.getInstance() is called the first time.

The simplest lazy initialisation is to use an enum with one instance.
enum Singleton {
INSTANCE; // lazy initialised
}
The added problem is you want initialisation values. To handle this you can nest the class.
enum Utility {;
static MyType val;
static OtherType val2;
enum Holder {
INSTANCE;
Holder() {
// uses val and val2
}
}
public static Holder getInstance(MyType val, OtherType val2) {
Utility.val = val;
Utility.val2 = val2;
return Holder.INSTANCE; // only created the first time.
}
}
Note: this is thread safe as static block initialisation is safe.

Something like:
public static abstract class Lazy<T> {
private T t = null;
public synchronized T get() {
if (t == null) {
t = create();
}
return t;
}
protected abstract T create();
}
public static final Lazy<List<String>> lazyList = new Lazy<List<String>>(){
#Override
protected List<String> create() {
return new ArrayList<String>();
}
};

I'll caution you up front, what you're describing has a bit of code smell, and I suspect you'll do better to avoid this pattern entirely. A static resource that depends on external runtime state breaks all sorts of best practices about variable scope.
What you're describing, however, would best be implemented by either a Supplier or a Future, depending on the work involved in successfully constructing the object you need. The difference is somewhat pedantic, but you'd generally use a Future to hold a reference that will take a long time to compute, while a Supplier generally returns quickly. Future also has some nice hook-ins with Java's concurrency utilities, but by the sound of it you don't need that.
You'd use a Supplier like so:
public class GlobalState {
public static final Supplier<LazyData> MY_DATA = Suppliers.memoize(
new Supplier<LazyData>() {
public LazyData get() {
// do whatever you need to construct your object, only gets executed once needed
}
});
...
}
Suppliers.memoize() will cache the result of the first call to the underlying Supplier in a threadsafe way, so simply wrapping the Supplier you define with this call prevents duplicate processing.

Related

Can anyone help me with the Singleton in java [duplicate]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
What is an efficient way to implement a singleton design pattern in Java?

Use an enum:
public enum Foo {
INSTANCE;
}
Joshua Bloch explained this approach in his Effective Java Reloaded talk at Google I/O 2008: link to video. Also see slides 30-32 of his presentation (effective_java_reloaded.pdf):
The Right Way to Implement a Serializable Singleton
public enum Elvis {
INSTANCE;
private final String[] favoriteSongs =
{ "Hound Dog", "Heartbreak Hotel" };
public void printFavorites() {
System.out.println(Arrays.toString(favoriteSongs));
}
}
Edit: An online portion of "Effective Java" says:
"This approach is functionally equivalent to the public field approach, except that it is more concise, provides the serialization machinery for free, and provides an ironclad guarantee against multiple instantiation, even in the face of sophisticated serialization or reflection attacks. While this approach has yet to be widely adopted, a single-element enum type is the best way to implement a singleton."

Depending on the usage, there are several "correct" answers.
Since Java 5, the best way to do it is to use an enum:
public enum Foo {
INSTANCE;
}
Pre Java 5, the most simple case is:
public final class Foo {
private static final Foo INSTANCE = new Foo();
private Foo() {
if (INSTANCE != null) {
throw new IllegalStateException("Already instantiated");
}
}
public static Foo getInstance() {
return INSTANCE;
}
public Object clone() throws CloneNotSupportedException{
throw new CloneNotSupportedException("Cannot clone instance of this class");
}
}
Let's go over the code. First, you want the class to be final. In this case, I've used the final keyword to let the users know it is final. Then you need to make the constructor private to prevent users to create their own Foo. Throwing an exception from the constructor prevents users to use reflection to create a second Foo. Then you create a private static final Foo field to hold the only instance, and a public static Foo getInstance() method to return it. The Java specification makes sure that the constructor is only called when the class is first used.
When you have a very large object or heavy construction code and also have other accessible static methods or fields that might be used before an instance is needed, then and only then you need to use lazy initialization.
You can use a private static class to load the instance. The code would then look like:
public final class Foo {
private static class FooLoader {
private static final Foo INSTANCE = new Foo();
}
private Foo() {
if (FooLoader.INSTANCE != null) {
throw new IllegalStateException("Already instantiated");
}
}
public static Foo getInstance() {
return FooLoader.INSTANCE;
}
}
Since the line private static final Foo INSTANCE = new Foo(); is only executed when the class FooLoader is actually used, this takes care of the lazy instantiation, and is it guaranteed to be thread safe.
When you also want to be able to serialize your object you need to make sure that deserialization won't create a copy.
public final class Foo implements Serializable {
private static final long serialVersionUID = 1L;
private static class FooLoader {
private static final Foo INSTANCE = new Foo();
}
private Foo() {
if (FooLoader.INSTANCE != null) {
throw new IllegalStateException("Already instantiated");
}
}
public static Foo getInstance() {
return FooLoader.INSTANCE;
}
#SuppressWarnings("unused")
private Foo readResolve() {
return FooLoader.INSTANCE;
}
}
The method readResolve() will make sure the only instance will be returned, even when the object was serialized in a previous run of your program.

Disclaimer: I have just summarized all of the awesome answers and wrote it in my own words.
While implementing Singleton we have two options:
Lazy loading
Early loading
Lazy loading adds bit overhead (lots of to be honest), so use it only when you have a very large object or heavy construction code and also have other accessible static methods or fields that might be used before an instance is needed, then and only then you need to use lazy initialization. Otherwise, choosing early loading is a good choice.
The most simple way of implementing a singleton is:
public class Foo {
// It will be our sole hero
private static final Foo INSTANCE = new Foo();
private Foo() {
if (INSTANCE != null) {
// SHOUT
throw new IllegalStateException("Already instantiated");
}
}
public static Foo getInstance() {
return INSTANCE;
}
}
Everything is good except it's an early loaded singleton. Lets try lazy loaded singleton
class Foo {
// Our now_null_but_going_to_be sole hero
private static Foo INSTANCE = null;
private Foo() {
if (INSTANCE != null) {
// SHOUT
throw new IllegalStateException("Already instantiated");
}
}
public static Foo getInstance() {
// Creating only when required.
if (INSTANCE == null) {
INSTANCE = new Foo();
}
return INSTANCE;
}
}
So far so good, but our hero will not survive while fighting alone with multiple evil threads who want many many instance of our hero.
So let’s protect it from evil multi threading:
class Foo {
private static Foo INSTANCE = null;
// TODO Add private shouting constructor
public static Foo getInstance() {
// No more tension of threads
synchronized (Foo.class) {
if (INSTANCE == null) {
INSTANCE = new Foo();
}
}
return INSTANCE;
}
}
But it is not enough to protect out hero, really!!! This is the best we can/should do to help our hero:
class Foo {
// Pay attention to volatile
private static volatile Foo INSTANCE = null;
// TODO Add private shouting constructor
public static Foo getInstance() {
if (INSTANCE == null) { // Check 1
synchronized (Foo.class) {
if (INSTANCE == null) { // Check 2
INSTANCE = new Foo();
}
}
}
return INSTANCE;
}
}
This is called the "double-checked locking idiom". It's easy to forget the volatile statement and difficult to understand why it is necessary.
For details: The "Double-Checked Locking is Broken" Declaration
Now we are sure about evil threads, but what about the cruel serialization? We have to make sure even while de-serialiaztion no new object is created:
class Foo implements Serializable {
private static final long serialVersionUID = 1L;
private static volatile Foo INSTANCE = null;
// The rest of the things are same as above
// No more fear of serialization
#SuppressWarnings("unused")
private Object readResolve() {
return INSTANCE;
}
}
The method readResolve() will make sure the only instance will be returned, even when the object was serialized in a previous run of our program.
Finally, we have added enough protection against threads and serialization, but our code is looking bulky and ugly. Let’s give our hero a makeover:
public final class Foo implements Serializable {
private static final long serialVersionUID = 1L;
// Wrapped in a inner static class so that loaded only when required
private static class FooLoader {
// And no more fear of threads
private static final Foo INSTANCE = new Foo();
}
// TODO add private shouting construcor
public static Foo getInstance() {
return FooLoader.INSTANCE;
}
// Damn you serialization
#SuppressWarnings("unused")
private Foo readResolve() {
return FooLoader.INSTANCE;
}
}
Yes, this is our very same hero :)
Since the line private static final Foo INSTANCE = new Foo(); is only executed when the class FooLoader is actually used, this takes care of the lazy instantiation, and is it guaranteed to be thread-safe.
And we have come so far. Here is the best way to achieve everything we did is best possible way:
public enum Foo {
INSTANCE;
}
Which internally will be treated like
public class Foo {
// It will be our sole hero
private static final Foo INSTANCE = new Foo();
}
That's it! No more fear of serialization, threads and ugly code. Also ENUMS singleton are lazily initialized.
This approach is functionally equivalent to the public field approach,
except that it is more concise, provides the serialization machinery
for free, and provides an ironclad guarantee against multiple
instantiation, even in the face of sophisticated serialization or
reflection attacks. While this approach has yet to be widely adopted,
a single-element enum type is the best way to implement a singleton.
-Joshua Bloch in "Effective Java"
Now you might have realized why ENUMS are considered as best way to implement a singleton and thanks for your patience :)
Updated it on my blog.

The solution posted by Stu Thompson is valid in Java 5.0 and later. But I would prefer not to use it because I think it is error prone.
It's easy to forget the volatile statement and difficult to understand why it is necessary. Without the volatile this code would not be thread safe any more due to the double-checked locking antipattern. See more about this in paragraph 16.2.4 of Java Concurrency in Practice. In short: This pattern (prior to Java 5.0 or without the volatile statement) could return a reference to the Bar object that is (still) in an incorrect state.
This pattern was invented for performance optimization. But this is really not a real concern any more. The following lazy initialization code is fast and - more importantly - easier to read.
class Bar {
private static class BarHolder {
public static Bar bar = new Bar();
}
public static Bar getBar() {
return BarHolder.bar;
}
}

Thread safe in Java 5+:
class Foo {
private static volatile Bar bar = null;
public static Bar getBar() {
if (bar == null) {
synchronized(Foo.class) {
if (bar == null)
bar = new Bar();
}
}
return bar;
}
}
Pay attention to the volatile modifier here. :) It is important because without it, other threads are not guaranteed by the JMM (Java Memory Model) to see changes to its value. The synchronization does not take care of that--it only serializes access to that block of code.
#Bno's answer details the approach recommended by Bill Pugh (FindBugs) and is arguable better. Go read and vote up his answer too.

Forget lazy initialization; it's too problematic. This is the simplest solution:
public class A {
private static final A INSTANCE = new A();
private A() {}
public static A getInstance() {
return INSTANCE;
}
}

Make sure that you really need it. Do a google search for "singleton anti-pattern" to see some arguments against it.
There's nothing inherently wrong with it I suppose, but it's just a mechanism for exposing some global resource/data so make sure that this is the best way. In particular, I've found dependency injection (DI) more useful particularly if you are also using unit tests, because DI allows you to use mocked resources for testing purposes.

I'm mystified by some of the answers that suggest dependency injection (DI) as an alternative to using singletons; these are unrelated concepts. You can use DI to inject either singleton or non-singleton (e.g., per-thread) instances. At least this is true if you use Spring 2.x, I can't speak for other DI frameworks.
So my answer to the OP would be (in all but the most trivial sample code) to:
Use a DI framework like Spring Framework, then
Make it part of your DI configuration whether your dependencies are singletons, request scoped, session scoped, or whatever.
This approach gives you a nice decoupled (and therefore flexible and testable) architecture where whether to use a singleton is an easily reversible implementation detail (provided any singletons you use are threadsafe, of course).

Really consider why you need a singleton before writing it. There is a quasi-religious debate about using them which you can quite easily stumble over if you google singletons in Java.
Personally, I try to avoid singletons as often as possible for many reasons, again most of which can be found by googling singletons. I feel that quite often singletons are abused because they're easy to understand by everybody. They're used as a mechanism for getting "global" data into an OO design and they are used because it is easy to circumvent object lifecycle management (or really thinking about how you can do A from inside B). Look at things like inversion of control (IoC) or dependency injection (DI) for a nice middle ground.
If you really need one then Wikipedia has a good example of a proper implementation of a singleton.

Following are three different approaches
Enum
/**
* Singleton pattern example using Java Enum
*/
public enum EasySingleton {
INSTANCE;
}
Double checked locking / lazy loading
/**
* Singleton pattern example with Double checked Locking
*/
public class DoubleCheckedLockingSingleton {
private static volatile DoubleCheckedLockingSingleton INSTANCE;
private DoubleCheckedLockingSingleton() {}
public static DoubleCheckedLockingSingleton getInstance() {
if(INSTANCE == null) {
synchronized(DoubleCheckedLockingSingleton.class) {
// Double checking Singleton instance
if(INSTANCE == null) {
INSTANCE = new DoubleCheckedLockingSingleton();
}
}
}
return INSTANCE;
}
}
Static factory method
/**
* Singleton pattern example with static factory method
*/
public class Singleton {
// Initialized during class loading
private static final Singleton INSTANCE = new Singleton();
// To prevent creating another instance of 'Singleton'
private Singleton() {}
public static Singleton getSingleton() {
return INSTANCE;
}
}

There is a lot of nuance around implementing a singleton. The holder pattern can not be used in many situations. And IMO when using a volatile - you should also use a local variable. Let's start at the beginning and iterate on the problem. You'll see what I mean.
The first attempt might look something like this:
public class MySingleton {
private static MySingleton INSTANCE;
public static MySingleton getInstance() {
if (INSTANCE == null) {
INSTANCE = new MySingleton();
}
return INSTANCE;
}
...
}
Here we have the MySingleton class which has a private static member called INSTANCE, and a public static method called getInstance(). The first time getInstance() is called, the INSTANCE member is null. The flow will then fall into the creation condition and create a new instance of the MySingleton class. Subsequent calls to getInstance() will find that the INSTANCE variable is already set, and therefore not create another MySingleton instance. This ensures there is only one instance of MySingleton which is shared among all callers of getInstance().
But this implementation has a problem. Multi-threaded applications will have a race condition on the creation of the single instance. If multiple threads of execution hit the getInstance() method at (or around) the same time, they will each see the INSTANCE member as null. This will result in each thread creating a new MySingleton instance and subsequently setting the INSTANCE member.
private static MySingleton INSTANCE;
public static synchronized MySingleton getInstance() {
if (INSTANCE == null) {
INSTANCE = new MySingleton();
}
return INSTANCE;
}
Here we’ve used the synchronized keyword in the method signature to synchronize the getInstance() method. This will certainly fix our race condition. Threads will now block and enter the method one at a time. But it also creates a performance problem. Not only does this implementation synchronize the creation of the single instance; it synchronizes all calls to getInstance(), including reads. Reads do not need to be synchronized as they simply return the value of INSTANCE. Since reads will make up the bulk of our calls (remember, instantiation only happens on the first call), we will incur an unnecessary performance hit by synchronizing the entire method.
private static MySingleton INSTANCE;
public static MySingleton getInstance() {
if (INSTANCE == null) {
synchronize(MySingleton.class) {
INSTANCE = new MySingleton();
}
}
return INSTANCE;
}
Here we’ve moved synchronization from the method signature, to a synchronized block that wraps the creation of the MySingleton instance. But does this solve our problem? Well, we are no longer blocking on reads, but we’ve also taken a step backward. Multiple threads will hit the getInstance() method at or around the same time and they will all see the INSTANCE member as null.
They will then hit the synchronized block where one will obtain the lock and create the instance. When that thread exits the block, the other threads will contend for the lock, and one by one each thread will fall through the block and create a new instance of our class. So we are right back where we started.
private static MySingleton INSTANCE;
public static MySingleton getInstance() {
if (INSTANCE == null) {
synchronized(MySingleton.class) {
if (INSTANCE == null) {
INSTANCE = createInstance();
}
}
}
return INSTANCE;
}
Here we issue another check from inside the block. If the INSTANCE member has already been set, we’ll skip initialization. This is called double-checked locking.
This solves our problem of multiple instantiation. But once again, our solution has presented another challenge. Other threads might not “see” that the INSTANCE member has been updated. This is because of how Java optimizes memory operations.
Threads copy the original values of variables from main memory into the CPU’s cache. Changes to values are then written to, and read from, that cache. This is a feature of Java designed to optimize performance. But this creates a problem for our singleton implementation. A second thread — being processed by a different CPU or core, using a different cache — will not see the changes made by the first. This will cause the second thread to see the INSTANCE member as null forcing a new instance of our singleton to be created.
private static volatile MySingleton INSTANCE;
public static MySingleton getInstance() {
if (INSTANCE == null) {
synchronized(MySingleton.class) {
if (INSTANCE == null) {
INSTANCE = createInstance();
}
}
}
return INSTANCE;
}
We solve this by using the volatile keyword on the declaration of the INSTANCE member. This will tell the compiler to always read from, and write to, main memory, and not the CPU cache.
But this simple change comes at a cost. Because we are bypassing the CPU cache, we will take a performance hit each time we operate on the volatile INSTANCE member — which we do four times. We double-check existence (1 and 2), set the value (3), and then return the value (4). One could argue that this path is the fringe case as we only create the instance during the first call of the method. Perhaps a performance hit on creation is tolerable. But even our main use-case, reads, will operate on the volatile member twice. Once to check existence, and again to return its value.
private static volatile MySingleton INSTANCE;
public static MySingleton getInstance() {
MySingleton result = INSTANCE;
if (result == null) {
synchronized(MySingleton.class) {
result = INSTANCE;
if (result == null) {
INSTANCE = result = createInstance();
}
}
}
return result;
}
Since the performance hit is due to operating directly on the volatile member, let’s set a local variable to the value of the volatile and operate on the local variable instead. This will decrease the number of times we operate on the volatile, thereby reclaiming some of our lost performance. Note that we have to set our local variable again when we enter the synchronized block. This ensures it is up to date with any changes that occurred while we were waiting for the lock.
I wrote an article about this recently. Deconstructing The Singleton. You can find more information on these examples and an example of the "holder" pattern there. There is also a real-world example showcasing the double-checked volatile approach.

I use the Spring Framework to manage my singletons.
It doesn't enforce the "singleton-ness" of the class (which you can't really do anyway if there are multiple class loaders involved), but it provides a really easy way to build and configure different factories for creating different types of objects.

Wikipedia has some examples of singletons, also in Java. The Java 5 implementation looks pretty complete, and is thread-safe (double-checked locking applied).

Version 1:
public class MySingleton {
private static MySingleton instance = null;
private MySingleton() {}
public static synchronized MySingleton getInstance() {
if(instance == null) {
instance = new MySingleton();
}
return instance;
}
}
Lazy loading, thread safe with blocking, low performance because of synchronized.
Version 2:
public class MySingleton {
private MySingleton() {}
private static class MySingletonHolder {
public final static MySingleton instance = new MySingleton();
}
public static MySingleton getInstance() {
return MySingletonHolder.instance;
}
}
Lazy loading, thread safe with non-blocking, high performance.

If you do not need lazy loading then simply try:
public class Singleton {
private final static Singleton INSTANCE = new Singleton();
private Singleton() {}
public static Singleton getInstance() { return Singleton.INSTANCE; }
protected Object clone() {
throw new CloneNotSupportedException();
}
}
If you want lazy loading and you want your singleton to be thread-safe, try the double-checking pattern:
public class Singleton {
private static Singleton instance = null;
private Singleton() {}
public static Singleton getInstance() {
if(null == instance) {
synchronized(Singleton.class) {
if(null == instance) {
instance = new Singleton();
}
}
}
return instance;
}
protected Object clone() {
throw new CloneNotSupportedException();
}
}
As the double checking pattern is not guaranteed to work (due to some issue with compilers, I don't know anything more about that), you could also try to synchronize the whole getInstance-method or create a registry for all your singletons.

I would say an enum singleton.
Singleton using an enum in Java is generally a way to declare an enum singleton. An enum singleton may contain instance variables and instance methods. For simplicity's sake, also note that if you are using any instance method then you need to ensure thread safety of that method if at all it affects the state of object.
The use of an enum is very easy to implement and has no drawbacks regarding serializable objects, which have to be circumvented in the other ways.
/**
* Singleton pattern example using a Java Enum
*/
public enum Singleton {
INSTANCE;
public void execute (String arg) {
// Perform operation here
}
}
You can access it by Singleton.INSTANCE, and it is much easier than calling the getInstance() method on Singleton.
1.12 Serialization of Enum Constants
Enum constants are serialized differently than ordinary serializable or externalizable objects. The serialized form of an enum constant consists solely of its name; field values of the constant are not present in the form. To serialize an enum constant, ObjectOutputStream writes the value returned by the enum constant's name method. To deserialize an enum constant, ObjectInputStream reads the constant name from the stream; the deserialized constant is then obtained by calling the java.lang.Enum.valueOf method, passing the constant's enum type along with the received constant name as arguments. Like other serializable or externalizable objects, enum constants can function as the targets of back references appearing subsequently in the serialization stream.
The process by which enum constants are serialized cannot be customized: any class-specific writeObject, readObject, readObjectNoData, writeReplace, and readResolve methods defined by enum types are ignored during serialization and deserialization. Similarly, any serialPersistentFields or serialVersionUID field declarations are also ignored--all enum types have a fixed serialVersionUID of 0L. Documenting serializable fields and data for enum types is unnecessary, since there is no variation in the type of data sent.
Quoted from Oracle documentation
Another problem with conventional Singletons are that once you implement the Serializable interface, they no longer remain singleton because the readObject() method always return a new instance, like a constructor in Java. This can be avoided by using readResolve() and discarding the newly created instance by replacing with a singleton like below:
// readResolve to prevent another instance of Singleton
private Object readResolve(){
return INSTANCE;
}
This can become even more complex if your singleton class maintains state, as you need to make them transient, but with in an enum singleton, serialization is guaranteed by the JVM.
Good Read
Singleton Pattern
Enums, Singletons and Deserialization
Double-checked locking and the Singleton pattern

There are four ways to create a singleton in Java.
Eager initialization singleton
public class Test {
private static final Test test = new Test();
private Test() {
}
public static Test getTest() {
return test;
}
}
Lazy initialization singleton (thread safe)
public class Test {
private static volatile Test test;
private Test() {
}
public static Test getTest() {
if(test == null) {
synchronized(Test.class) {
if(test == null) {
test = new Test();
}
}
}
return test;
}
}
Bill Pugh singleton with holder pattern (preferably the best one)
public class Test {
private Test() {
}
private static class TestHolder {
private static final Test test = new Test();
}
public static Test getInstance() {
return TestHolder.test;
}
}
Enum singleton
public enum MySingleton {
INSTANCE;
private MySingleton() {
System.out.println("Here");
}
}

This is how to implement a simple singleton:
public class Singleton {
// It must be static and final to prevent later modification
private static final Singleton INSTANCE = new Singleton();
/** The constructor must be private to prevent external instantiation */
private Singleton(){}
/** The public static method allowing to get the instance */
public static Singleton getInstance() {
return INSTANCE;
}
}
This is how to properly lazy create your singleton:
public class Singleton {
// The constructor must be private to prevent external instantiation
private Singleton(){}
/** The public static method allowing to get the instance */
public static Singleton getInstance() {
return SingletonHolder.INSTANCE;
}
/**
* The static inner class responsible for creating your instance only on demand,
* because the static fields of a class are only initialized when the class
* is explicitly called and a class initialization is synchronized such that only
* one thread can perform it, this rule is also applicable to inner static class
* So here INSTANCE will be created only when SingletonHolder.INSTANCE
* will be called
*/
private static class SingletonHolder {
private static final Singleton INSTANCE = new Singleton();
}
}

You need the double-checking idiom if you need to load the instance variable of a class lazily. If you need to load a static variable or a singleton lazily, you need the initialization on demand holder idiom.
In addition, if the singleton needs to be serializable, all other fields need to be transient and readResolve() method needs to be implemented in order to maintain the singleton object invariant. Otherwise, each time the object is deserialized, a new instance of the object will be created. What readResolve() does is replace the new object read by readObject(), which forced that new object to be garbage collected as there is no variable referring to it.
public static final INSTANCE == ....
private Object readResolve() {
return INSTANCE; // Original singleton instance.
}

Various ways to make a singleton object:
As per Joshua Bloch - Enum would be the best.
You can use double check locking also.
Even an inner static class can be used.

Enum singleton
The simplest way to implement a singleton that is thread-safe is using an Enum:
public enum SingletonEnum {
INSTANCE;
public void doSomething(){
System.out.println("This is a singleton");
}
}
This code works since the introduction of Enum in Java 1.5
Double checked locking
If you want to code a “classic” singleton that works in a multithreaded environment (starting from Java 1.5) you should use this one.
public class Singleton {
private static volatile Singleton instance = null;
private Singleton() {
}
public static Singleton getInstance() {
if (instance == null) {
synchronized (Singleton.class){
if (instance == null) {
instance = new Singleton();
}
}
}
return instance;
}
}
This is not thread-safe before 1.5 because the implementation of the volatile keyword was different.
Early loading singleton (works even before Java 1.5)
This implementation instantiates the singleton when the class is loaded and provides thread safety.
public class Singleton {
private static final Singleton instance = new Singleton();
private Singleton() {
}
public static Singleton getInstance() {
return instance;
}
public void doSomething(){
System.out.println("This is a singleton");
}
}

For JSE 5.0 and above, take the Enum approach. Otherwise, use the static singleton holder approach ((a lazy loading approach described by Bill Pugh). The latter solution is also thread-safe without requiring special language constructs (i.e., volatile or synchronized).

Another argument often used against singletons is their testability problems. Singletons are not easily mockable for testing purposes. If this turns out to be a problem, I like to make the following slight modification:
public class SingletonImpl {
private static SingletonImpl instance;
public static SingletonImpl getInstance() {
if (instance == null) {
instance = new SingletonImpl();
}
return instance;
}
public static void setInstance(SingletonImpl impl) {
instance = impl;
}
public void a() {
System.out.println("Default Method");
}
}
The added setInstance method allows setting a mockup implementation of the singleton class during testing:
public class SingletonMock extends SingletonImpl {
#Override
public void a() {
System.out.println("Mock Method");
}
}
This also works with early initialization approaches:
public class SingletonImpl {
private static final SingletonImpl instance = new SingletonImpl();
private static SingletonImpl alt;
public static void setInstance(SingletonImpl inst) {
alt = inst;
}
public static SingletonImpl getInstance() {
if (alt != null) {
return alt;
}
return instance;
}
public void a() {
System.out.println("Default Method");
}
}
public class SingletonMock extends SingletonImpl {
#Override
public void a() {
System.out.println("Mock Method");
}
}
This has the drawback of exposing this functionality to the normal application too. Other developers working on that code could be tempted to use the ´setInstance´ method to alter a specific function and thus changing the whole application behaviour, and therefore this method should contain at least a good warning in its javadoc.
Still, for the possibility of mockup-testing (when needed), this code exposure may be an acceptable price to pay.

Simplest singleton class:
public class Singleton {
private static Singleton singleInstance = new Singleton();
private Singleton() {}
public static Singleton getSingleInstance() {
return singleInstance;
}
}

Have a look at this post.
Examples of GoF Design Patterns in Java's core libraries
From the best answer's "Singleton" section,
Singleton (recognizeable by creational methods returning the same instance (usually of itself) everytime)
java.lang.Runtime#getRuntime()
java.awt.Desktop#getDesktop()
java.lang.System#getSecurityManager()
You can also learn the example of Singleton from Java native classes themselves.

The best singleton pattern I've ever seen uses the Supplier interface.
It's generic and reusable
It supports lazy initialization
It's only synchronized until it has been initialized, then the blocking supplier is replaced with a non-blocking supplier.
See below:
public class Singleton<T> implements Supplier<T> {
private boolean initialized;
private Supplier<T> singletonSupplier;
public Singleton(T singletonValue) {
this.singletonSupplier = () -> singletonValue;
}
public Singleton(Supplier<T> supplier) {
this.singletonSupplier = () -> {
// The initial supplier is temporary; it will be replaced after initialization
synchronized (supplier) {
if (!initialized) {
T singletonValue = supplier.get();
// Now that the singleton value has been initialized,
// replace the blocking supplier with a non-blocking supplier
singletonSupplier = () -> singletonValue;
initialized = true;
}
return singletonSupplier.get();
}
};
}
#Override
public T get() {
return singletonSupplier.get();
}
}

I still think after Java 1.5, enum is the best available singleton implementation available as it also ensures that, even in the multi threaded environments, only one instance is created.
public enum Singleton {
INSTANCE;
}
And you are done!

Sometimes a simple "static Foo foo = new Foo();" is not enough. Just think of some basic data insertion you want to do.
On the other hand you would have to synchronize any method that instantiates the singleton variable as such. Synchronisation is not bad as such, but it can lead to performance issues or locking (in very very rare situations using this example. The solution is
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;
}
}
Now what happens? The class is loaded via the class loader. Directly after the class was interpreted from a byte Array, the VM executes the static { } - block. that's the whole secret: The static-block is only called once, the time the given class (name) of the given package is loaded by this one class loader.

public class Singleton {
private static final Singleton INSTANCE = new Singleton();
private Singleton() {
if (INSTANCE != null)
throw new IllegalStateException(“Already instantiated...”);
}
public synchronized static Singleton getInstance() {
return INSTANCE;
}
}
As we have added the Synchronized keyword before getInstance, we have avoided the race condition in the case when two threads call the getInstance at the same time.

Is this implementation of singleton thread safe, serialization problem free and performant?

I have a singleton that keeps its current state inside of an enum. I want to be sure that this implementation is thread-safe, does not have serialization issues and is performant. It is being used for central configuration and to dynamically change the configuration at run-time.
May anyone please point out any issues that you can find. I realize the synchronized blocks may slow the access to an internal enum value.
The set operation is not called very often maybe once a day, but the get operation is called 200-600 times an hour.
I have tried running this with different threads accessing the value and setting value in the enum.
import java.io.Serializable;
public class ProviderSingleton implements Serializable {
private static final long serialVersionUID = -6827317560255793250L;
private static volatile EmailProvider emailProvider;
private static ProviderSingleton instance = new ProviderSingleton();
private ProviderSingleton() {
System.out.println("Singleton(): Initializing Instance");
emailProvider = EmailProvider.SMTP; // the default
}
public static ProviderSingleton getInstance() {
return instance;
}
public String getEmailProvider() {
synchronized (ProviderSingleton.class) {
return emailProvider.name().toString();
}
}
public void setEmailProvider(String emailProviderValue) {
synchronized (ProviderSingleton.class) {
emailProvider = EmailProvider.valueOf(emailProviderValue);
}
}
// This method is called immediately after an object of this class is
// deserialized.This method returns the singleton instance.
protected ProviderSingleton readResolve() {
return getInstance();
}
enum EmailProvider {
SMTP, POP3;
}
}
I am hopping issues can be pointed out or improvements suggested with code examples.

Creating many objects using composition when the containing class is a singleton pattern

java version 1.7.0_65
I have a singleton design pattern class. That will always return the same instance that is initially created.
However, the problem I have is this class needs to create many other objects from another class. I have used composition for this (instance of POI class in ArlabFacade). From this singleton instance the client should be able to create many POI objects. And I don't want to expose the internal workings of the POI class, everything has to go through the singleton instance.
private static ArlabFacade mArlabFacade = null;
private POI mPoi; /* Should be able to create many object of this class */
private ArlabFacade(Context context) {
/* initialize properties */
mContext = context;
mPoi = null;
}
public static ArlabFacade getInstance(Context context) {
/* Create a synchronised singleton instance */
ReentrantLock lock = new ReentrantLock();
lock.lock();
if(mArlabFacade == null) {
mArlabFacade = new ArlabFacade(context);
}
lock.unlock();
return mArlabFacade;
}
I have tried doing something like this, but it has 2 problems.
1) I don't want to return the class instance of POI
2) because I only have a single instance the mPoi will be overwritten by the next client call to this function.
This function will just overwrite:
public POI createNewPOI() {
return mPoi = new POI();
}
Is there any design patterns that address this problem?

I'm a bit confused what exactly you are trying to achieve. It looks like you want a Factory, i.e. a class that hides how to create objects of a certain class. There is no need for a Singleton in that case, unless you have other reasons.
As to your problems:
You are nor returning a class instance, but an object of that class. I thought that was the whole point: creating that POI object ant returning it. I guess there is some confusion about the nomenclature, so please explain what you mean by class instance, and why you don't want to return it.
In your factory method createNewPOI() you just overwrite your reference to the last created POI object, not the object itself. Unless your factory class (resp. your Singleton) is doing something with the POI object itself, there is no need to keep a reference. You return the object to the caller of the method. After that you can just forget it:
.
public POI createNewPOI() {
return new POI();
}
There is one more problem in your code: Your locking in the getInstance() method won't work. For a ReentrantLock to do its job it has to be shared between multiple threads. In your case each thread creates its own copy of the lock, without knowing of the other theads.
The easiest way is to just make the method synchronized:
public static synchronized ArlabFacade getInstance(Context context) {
if(mArlabFacade == null) {
mArlabFacade = new ArlabFacade(context);
}
return mArlabFacade;
}

Take a look at: What is so bad about singletons?
You should only use code patterns if you have a reason. Ex: opular patterns and reasons to use them are:
Creational Patterns
Abstract Factory Creates an instance of several families of classes
Builder Separates object construction from its representation
Factory Method Creates an instance of several derived classes
Prototype A fully initialized instance to be copied or cloned
Singleton A class of which only a single instance can exist
Structural Patterns
Adapter Match interfaces of different classes
Bridge Separates an object’s interface from its implementation
Composite A tree structure of simple and composite objects
Decorator Add responsibilities to objects dynamically
Facade A single class that represents an entire subsystem
Flyweight A fine-grained instance used for efficient sharing
Proxy An object representing another object
Behavioral Patterns
Chain of Resp. A way of passing a request between a chain of objects
Command Encapsulate a command request as an object
Interpreter A way to include language elements in a program
Iterator Sequentially access the elements of a collection
Mediator Defines simplified communication between classes
Memento Capture and restore an object's internal state
Observer A way of notifying change to a number of classes
State Alter an object's behavior when its state changes
Strategy Encapsulates an algorithm inside a class
Template Method Defer the exact steps of an algorithm to a subclass
Visitor Defines a new operation to a class without change
source : dofactory

Quite simple, but first of all, please note, that lock must be created within the static context, so that every thread will use the same lock instance (there will be no synchronization at all if using the different instance for each thread)
Now, here is the code
public class ArlabFacade {
private static ArlabFacade mArlabFacade = null;
/* Create a synchronised singleton instance */
private static final ReentrantLock lock = new ReentrantLock();
private ArlabFacade(Context context) {
/* initialize properties */
mContext = context;
}
public static ArlabFacade getInstance(Context context) {
lock.lock();
if(mArlabFacade == null) {
mArlabFacade = new ArlabFacade(context);
}
lock.unlock();
return mArlabFacade;
}
public NotAPOI createNewPOI() {
return new NotAPOIImpl(new POI());
}
public void doSomething(NotAPOI val) {
if(!(val instanceof NotAPOIImpl)) {
throw new IllegalArgumentException("Illegal implementation of NotAPOI");
}
NotAPOIImpl impl = (NotAPOIImpl) val;
POI poi = val.poi;
// do something with poi here
}
private static class NotAPOIImpl implements NotAPOI {
private POI poi;
private NotAPOIImpl(POI poi) {
this.poi = poi;
}
}
}
// As you don't like to expose the POI just hide it behind the interface
public interface NotAPOI {
}
Another possible solution is to allow to work with POI by means of one more level of abstraction, which is more elegant
public class ArlabFacade {
private static ArlabFacade mArlabFacade = null;
/* Create a synchronised singleton instance */
private static final ReentrantLock lock = new ReentrantLock();
private ArlabFacade(Context context) {
/* initialize properties */
mContext = context;
}
public static ArlabFacade getInstance(Context context) {
lock.lock();
if(mArlabFacade == null) {
mArlabFacade = new ArlabFacade(context);
}
lock.unlock();
return mArlabFacade;
}
public NotAPOI createNewPOI() {
return new NotAPOIImpl(new POI());
}
private static class NotAPOIImpl implements NotAPOI {
private POI poi;
private NotAPOIImpl(POI poi) {
this.poi = poi;
}
public void doSomething() {
poi.doSomething();
}
}
}
// As you don't like to expose the POI just hide it behind the interface
public interface NotAPOI {
void doSomething();
}

If I understand you correctly, you want all callers to get the same singleton class, but each caller to operate on his own POI Object. But this POI Object should be hidden in the Singleton-Class.
You can do it like this:
Each Callsite/Client will first have to call ArlabFacade.getInstance().generateToken() so he gets a unique Token, so he gets one POI reserved for use. And when he is done he should call releaseToken()
private static ArlabFacade mArlabFacade = null;
private HashMap<String, POI> poiMap = new ConcurrentHashMap<>();
private ArlabFacade(Context context) {
/* initialize properties */
mContext = context;
}
public static synchronized ArlabFacade getInstance(Context context) {
/* Create a synchronised singleton instance */
if(mArlabFacade == null) {
mArlabFacade = new ArlabFacade(context);
}
return mArlabFacade;
}
private AtomicInteger uniqueStringCounter = new AtomicInteger(0);
public String createUniqueString() {
return "TOKEN"+uniqueStringCounter.getAndIncrement();
}
public String generateToken() {
String token = createUniqueString();
poiMap.add(token, new POI());
}
public void releaseToken(String token) {
poiMap.remove(token);
}
public void doStuffOnPOI(String token, int someParameter) {
POI mPoi = poiMap.get(token);
mPoi.doStuff(someParam);
}

When writing lazy-loaded (on-demand) singleton in java, you must be aware of some problems:
Double-checked locking pattern is considered unsafe in multithreaded environment.
/*
* unsafe and broken Double-Checked Locking pattern
*/
public class ArlabFacade {
private ArlabFacade mArlabFacade;
public ArlabFacade getInstance() {
if (mArlabFacade == null) {
synchronized(this) {
if (mArlabFacade == null) {
mArlabFacade = new ArlabFacade(...);
}
}
}
return mArlabFacade;
}
}
Double-checked locking pattern is bad due to Java Memory Model described in language specification.
See below links:
http://en.wikipedia.org/wiki/Double-checked_locking
http://www.javaworld.com/article/2074979/java-concurrency/double-checked-locking--clever--but-broken.html
From this point of view safe and valid pattern is called Initialization on Demand Holder and is shown below:
Fragment from wiki: "[...] In all versions of Java, the idiom enables a safe, highly concurrent lazy initialization with good performance [...]"
See:
http://en.wikipedia.org/wiki/Initialization-on-demand_holder_idiom
/*
* fully safe and performant holder pattern
*/
public class ArlabFacade {
private static class Holder {
private ArlabFacade instance;
private List<POI> mPOIs;
static {
instance = new ArlabFacade();
mPOIs = new ArrayList();
mPOIs.add( new POI(...) );
mPOIs.add( new POI(...) );
....
}
}
public static ArlabFacade getInstance() {
return Holder.instance;
}
}
Above holder pattern guarantees to be safe and performant becase static class Holder is loaded only once (JVM spec) and lazily - only when getInstance() is called for the first time.

Is this a valid way to ensure only a single instance of an object exists in Java?

I have been getting some strange errors with Mongodb, and in Mongodb, you are supposed to mainatin the Mongo singleton. I just wanted to make sure that this is infact valid.
public class DBManager {
public static Mongo mongoSingleton = null;
public static synchronized void getMongo(){
if(mongoSingleton == null){
mongoSingleton = new Mongo();
}
return mongoSingleton;
}
}
Thanks!

You have to set your public member mongoSingleton as private and to hide the default constructor
so
private static Mongo mongoSingleton = null;
private Mongo() {
}
the class Mongo implementation
public class Mongo {
private static volatile Mongo instance;
private Mongo() {
...
}
public static Mongo getInstance() {
if (instance == null) {
synchronized (Mongo.class) {
if (instance == null) { // yes double check
instance = new Mongo();
}
}
}
return instance;
}
}
usage
Mongo.getInstance();

This is the typical Singleton pattern, but the preferred method in Java is to create an Enum:
public enum DBManager {
INSTANCE;
// implementation here
}
You can then refer to the instance via:
DBManager.INSTANCE
Note that in either case (enum or singleton pattern), the result is one instance per ClassLoader, NOT per JVM.

public static Mongo mongoSingleton = null;
needs to be
private static Mongo mongoSingleton = null;
Other than that, looks good.

The cheapest way to do this, if you are willing to forego Lazy initialization, is to simply create the Singleton on object creation.
public final class DBManager {
private static final Mongo mongoSingleton = new Mongo();
private DBManager() {}
public static Mongo getMongo() {
return mongoSingleton;
}
}
This way, you can avoid the unnecessary synchronization overhead which would otherwise be present on every call to this method. As long as Mongo itself is thread safe, your getMongo() method is thread-safe as well.
Read the Sun developer article on Singletons here.

Just use private static final Mongo mongo = new Mongo(), or even public static final Mongo mongo = new Mongo(). It's simpler and potentially faster.

no, because public access to the static member you can change it to whatever instance you want.
More sane would be the following
public class DBManager {
private static Mongo mongoSingleton = new Mongo();
public static Mongo getMongo(){
return mongoSingleton;
}
}

Lazy initialization of singletons is overrated, usually not necessary and causes more problems than good. The naive approach to make the whole static getter synchronized is bad, because the synchronization (which is a time consuming operation) is performed every time.
There are some better approaches such as double-checked locking or the initialization-on-demand holder, but the simplest and usually the best approach is Josh Bloch's enum approach. Make an enum with a single element and you get a bullet proof singleton.
public enum Mongo {
INSTANCE;
// instance fields, methods etc. as in any other class
}
This is almost functionally equivalent to a class with a private constructor and a public static final instance, but with more concise syntax and some nice under-the-hood features that unshakeably guarantee that no other instance can be created, not even through reflection or deserialization.
It is worth noting that this approach isn't necessarily eager. The single INSTANCE is created just after the Mongo class is loaded into the JVM, which doesn't happed right after the program starts - actually it happens on the first time the class is referenced - which in this case means on the first time a static field or a method is accessed.
And if there are no other static fields other that INSTANCE and no static methods, then this really happens after the first time the INSTANCE is accessed:
Mongo mongo = Mongo.INSTANCE;
In other words, it actually is lazy without the problems of explicit synchronization.

Yes but you don't want your member variable to be public. Users have to come via your synchronised getter

If you want to see in more details, step by step- you can follow this link- http://www.javabeginner.com/learn-java/java-singleton-design-pattern
Below is one example how to do it properly.
public class DBManager {
private static Mongo mongoSingleton = null;
public static synchronized void getMongo(){
if(mongoSingleton == null){
mongoSingleton = new Mongo();
}
return mongoSingleton;
}
}

What is an efficient way to implement a singleton pattern in Java? [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
What is an efficient way to implement a singleton design pattern in Java?

Use an enum:
public enum Foo {
INSTANCE;
}
Joshua Bloch explained this approach in his Effective Java Reloaded talk at Google I/O 2008: link to video. Also see slides 30-32 of his presentation (effective_java_reloaded.pdf):
The Right Way to Implement a Serializable Singleton
public enum Elvis {
INSTANCE;
private final String[] favoriteSongs =
{ "Hound Dog", "Heartbreak Hotel" };
public void printFavorites() {
System.out.println(Arrays.toString(favoriteSongs));
}
}
Edit: An online portion of "Effective Java" says:
"This approach is functionally equivalent to the public field approach, except that it is more concise, provides the serialization machinery for free, and provides an ironclad guarantee against multiple instantiation, even in the face of sophisticated serialization or reflection attacks. While this approach has yet to be widely adopted, a single-element enum type is the best way to implement a singleton."

Depending on the usage, there are several "correct" answers.
Since Java 5, the best way to do it is to use an enum:
public enum Foo {
INSTANCE;
}
Pre Java 5, the most simple case is:
public final class Foo {
private static final Foo INSTANCE = new Foo();
private Foo() {
if (INSTANCE != null) {
throw new IllegalStateException("Already instantiated");
}
}
public static Foo getInstance() {
return INSTANCE;
}
public Object clone() throws CloneNotSupportedException{
throw new CloneNotSupportedException("Cannot clone instance of this class");
}
}
Let's go over the code. First, you want the class to be final. In this case, I've used the final keyword to let the users know it is final. Then you need to make the constructor private to prevent users to create their own Foo. Throwing an exception from the constructor prevents users to use reflection to create a second Foo. Then you create a private static final Foo field to hold the only instance, and a public static Foo getInstance() method to return it. The Java specification makes sure that the constructor is only called when the class is first used.
When you have a very large object or heavy construction code and also have other accessible static methods or fields that might be used before an instance is needed, then and only then you need to use lazy initialization.
You can use a private static class to load the instance. The code would then look like:
public final class Foo {
private static class FooLoader {
private static final Foo INSTANCE = new Foo();
}
private Foo() {
if (FooLoader.INSTANCE != null) {
throw new IllegalStateException("Already instantiated");
}
}
public static Foo getInstance() {
return FooLoader.INSTANCE;
}
}
Since the line private static final Foo INSTANCE = new Foo(); is only executed when the class FooLoader is actually used, this takes care of the lazy instantiation, and is it guaranteed to be thread safe.
When you also want to be able to serialize your object you need to make sure that deserialization won't create a copy.
public final class Foo implements Serializable {
private static final long serialVersionUID = 1L;
private static class FooLoader {
private static final Foo INSTANCE = new Foo();
}
private Foo() {
if (FooLoader.INSTANCE != null) {
throw new IllegalStateException("Already instantiated");
}
}
public static Foo getInstance() {
return FooLoader.INSTANCE;
}
#SuppressWarnings("unused")
private Foo readResolve() {
return FooLoader.INSTANCE;
}
}
The method readResolve() will make sure the only instance will be returned, even when the object was serialized in a previous run of your program.

Disclaimer: I have just summarized all of the awesome answers and wrote it in my own words.
While implementing Singleton we have two options:
Lazy loading
Early loading
Lazy loading adds bit overhead (lots of to be honest), so use it only when you have a very large object or heavy construction code and also have other accessible static methods or fields that might be used before an instance is needed, then and only then you need to use lazy initialization. Otherwise, choosing early loading is a good choice.
The most simple way of implementing a singleton is:
public class Foo {
// It will be our sole hero
private static final Foo INSTANCE = new Foo();
private Foo() {
if (INSTANCE != null) {
// SHOUT
throw new IllegalStateException("Already instantiated");
}
}
public static Foo getInstance() {
return INSTANCE;
}
}
Everything is good except it's an early loaded singleton. Lets try lazy loaded singleton
class Foo {
// Our now_null_but_going_to_be sole hero
private static Foo INSTANCE = null;
private Foo() {
if (INSTANCE != null) {
// SHOUT
throw new IllegalStateException("Already instantiated");
}
}
public static Foo getInstance() {
// Creating only when required.
if (INSTANCE == null) {
INSTANCE = new Foo();
}
return INSTANCE;
}
}
So far so good, but our hero will not survive while fighting alone with multiple evil threads who want many many instance of our hero.
So let’s protect it from evil multi threading:
class Foo {
private static Foo INSTANCE = null;
// TODO Add private shouting constructor
public static Foo getInstance() {
// No more tension of threads
synchronized (Foo.class) {
if (INSTANCE == null) {
INSTANCE = new Foo();
}
}
return INSTANCE;
}
}
But it is not enough to protect out hero, really!!! This is the best we can/should do to help our hero:
class Foo {
// Pay attention to volatile
private static volatile Foo INSTANCE = null;
// TODO Add private shouting constructor
public static Foo getInstance() {
if (INSTANCE == null) { // Check 1
synchronized (Foo.class) {
if (INSTANCE == null) { // Check 2
INSTANCE = new Foo();
}
}
}
return INSTANCE;
}
}
This is called the "double-checked locking idiom". It's easy to forget the volatile statement and difficult to understand why it is necessary.
For details: The "Double-Checked Locking is Broken" Declaration
Now we are sure about evil threads, but what about the cruel serialization? We have to make sure even while de-serialiaztion no new object is created:
class Foo implements Serializable {
private static final long serialVersionUID = 1L;
private static volatile Foo INSTANCE = null;
// The rest of the things are same as above
// No more fear of serialization
#SuppressWarnings("unused")
private Object readResolve() {
return INSTANCE;
}
}
The method readResolve() will make sure the only instance will be returned, even when the object was serialized in a previous run of our program.
Finally, we have added enough protection against threads and serialization, but our code is looking bulky and ugly. Let’s give our hero a makeover:
public final class Foo implements Serializable {
private static final long serialVersionUID = 1L;
// Wrapped in a inner static class so that loaded only when required
private static class FooLoader {
// And no more fear of threads
private static final Foo INSTANCE = new Foo();
}
// TODO add private shouting construcor
public static Foo getInstance() {
return FooLoader.INSTANCE;
}
// Damn you serialization
#SuppressWarnings("unused")
private Foo readResolve() {
return FooLoader.INSTANCE;
}
}
Yes, this is our very same hero :)
Since the line private static final Foo INSTANCE = new Foo(); is only executed when the class FooLoader is actually used, this takes care of the lazy instantiation, and is it guaranteed to be thread-safe.
And we have come so far. Here is the best way to achieve everything we did is best possible way:
public enum Foo {
INSTANCE;
}
Which internally will be treated like
public class Foo {
// It will be our sole hero
private static final Foo INSTANCE = new Foo();
}
That's it! No more fear of serialization, threads and ugly code. Also ENUMS singleton are lazily initialized.
This approach is functionally equivalent to the public field approach,
except that it is more concise, provides the serialization machinery
for free, and provides an ironclad guarantee against multiple
instantiation, even in the face of sophisticated serialization or
reflection attacks. While this approach has yet to be widely adopted,
a single-element enum type is the best way to implement a singleton.
-Joshua Bloch in "Effective Java"
Now you might have realized why ENUMS are considered as best way to implement a singleton and thanks for your patience :)
Updated it on my blog.

The solution posted by Stu Thompson is valid in Java 5.0 and later. But I would prefer not to use it because I think it is error prone.
It's easy to forget the volatile statement and difficult to understand why it is necessary. Without the volatile this code would not be thread safe any more due to the double-checked locking antipattern. See more about this in paragraph 16.2.4 of Java Concurrency in Practice. In short: This pattern (prior to Java 5.0 or without the volatile statement) could return a reference to the Bar object that is (still) in an incorrect state.
This pattern was invented for performance optimization. But this is really not a real concern any more. The following lazy initialization code is fast and - more importantly - easier to read.
class Bar {
private static class BarHolder {
public static Bar bar = new Bar();
}
public static Bar getBar() {
return BarHolder.bar;
}
}

Thread safe in Java 5+:
class Foo {
private static volatile Bar bar = null;
public static Bar getBar() {
if (bar == null) {
synchronized(Foo.class) {
if (bar == null)
bar = new Bar();
}
}
return bar;
}
}
Pay attention to the volatile modifier here. :) It is important because without it, other threads are not guaranteed by the JMM (Java Memory Model) to see changes to its value. The synchronization does not take care of that--it only serializes access to that block of code.
#Bno's answer details the approach recommended by Bill Pugh (FindBugs) and is arguable better. Go read and vote up his answer too.

Forget lazy initialization; it's too problematic. This is the simplest solution:
public class A {
private static final A INSTANCE = new A();
private A() {}
public static A getInstance() {
return INSTANCE;
}
}

Make sure that you really need it. Do a google search for "singleton anti-pattern" to see some arguments against it.
There's nothing inherently wrong with it I suppose, but it's just a mechanism for exposing some global resource/data so make sure that this is the best way. In particular, I've found dependency injection (DI) more useful particularly if you are also using unit tests, because DI allows you to use mocked resources for testing purposes.

I'm mystified by some of the answers that suggest dependency injection (DI) as an alternative to using singletons; these are unrelated concepts. You can use DI to inject either singleton or non-singleton (e.g., per-thread) instances. At least this is true if you use Spring 2.x, I can't speak for other DI frameworks.
So my answer to the OP would be (in all but the most trivial sample code) to:
Use a DI framework like Spring Framework, then
Make it part of your DI configuration whether your dependencies are singletons, request scoped, session scoped, or whatever.
This approach gives you a nice decoupled (and therefore flexible and testable) architecture where whether to use a singleton is an easily reversible implementation detail (provided any singletons you use are threadsafe, of course).

Really consider why you need a singleton before writing it. There is a quasi-religious debate about using them which you can quite easily stumble over if you google singletons in Java.
Personally, I try to avoid singletons as often as possible for many reasons, again most of which can be found by googling singletons. I feel that quite often singletons are abused because they're easy to understand by everybody. They're used as a mechanism for getting "global" data into an OO design and they are used because it is easy to circumvent object lifecycle management (or really thinking about how you can do A from inside B). Look at things like inversion of control (IoC) or dependency injection (DI) for a nice middle ground.
If you really need one then Wikipedia has a good example of a proper implementation of a singleton.

Following are three different approaches
Enum
/**
* Singleton pattern example using Java Enum
*/
public enum EasySingleton {
INSTANCE;
}
Double checked locking / lazy loading
/**
* Singleton pattern example with Double checked Locking
*/
public class DoubleCheckedLockingSingleton {
private static volatile DoubleCheckedLockingSingleton INSTANCE;
private DoubleCheckedLockingSingleton() {}
public static DoubleCheckedLockingSingleton getInstance() {
if(INSTANCE == null) {
synchronized(DoubleCheckedLockingSingleton.class) {
// Double checking Singleton instance
if(INSTANCE == null) {
INSTANCE = new DoubleCheckedLockingSingleton();
}
}
}
return INSTANCE;
}
}
Static factory method
/**
* Singleton pattern example with static factory method
*/
public class Singleton {
// Initialized during class loading
private static final Singleton INSTANCE = new Singleton();
// To prevent creating another instance of 'Singleton'
private Singleton() {}
public static Singleton getSingleton() {
return INSTANCE;
}
}

There is a lot of nuance around implementing a singleton. The holder pattern can not be used in many situations. And IMO when using a volatile - you should also use a local variable. Let's start at the beginning and iterate on the problem. You'll see what I mean.
The first attempt might look something like this:
public class MySingleton {
private static MySingleton INSTANCE;
public static MySingleton getInstance() {
if (INSTANCE == null) {
INSTANCE = new MySingleton();
}
return INSTANCE;
}
...
}
Here we have the MySingleton class which has a private static member called INSTANCE, and a public static method called getInstance(). The first time getInstance() is called, the INSTANCE member is null. The flow will then fall into the creation condition and create a new instance of the MySingleton class. Subsequent calls to getInstance() will find that the INSTANCE variable is already set, and therefore not create another MySingleton instance. This ensures there is only one instance of MySingleton which is shared among all callers of getInstance().
But this implementation has a problem. Multi-threaded applications will have a race condition on the creation of the single instance. If multiple threads of execution hit the getInstance() method at (or around) the same time, they will each see the INSTANCE member as null. This will result in each thread creating a new MySingleton instance and subsequently setting the INSTANCE member.
private static MySingleton INSTANCE;
public static synchronized MySingleton getInstance() {
if (INSTANCE == null) {
INSTANCE = new MySingleton();
}
return INSTANCE;
}
Here we’ve used the synchronized keyword in the method signature to synchronize the getInstance() method. This will certainly fix our race condition. Threads will now block and enter the method one at a time. But it also creates a performance problem. Not only does this implementation synchronize the creation of the single instance; it synchronizes all calls to getInstance(), including reads. Reads do not need to be synchronized as they simply return the value of INSTANCE. Since reads will make up the bulk of our calls (remember, instantiation only happens on the first call), we will incur an unnecessary performance hit by synchronizing the entire method.
private static MySingleton INSTANCE;
public static MySingleton getInstance() {
if (INSTANCE == null) {
synchronize(MySingleton.class) {
INSTANCE = new MySingleton();
}
}
return INSTANCE;
}
Here we’ve moved synchronization from the method signature, to a synchronized block that wraps the creation of the MySingleton instance. But does this solve our problem? Well, we are no longer blocking on reads, but we’ve also taken a step backward. Multiple threads will hit the getInstance() method at or around the same time and they will all see the INSTANCE member as null.
They will then hit the synchronized block where one will obtain the lock and create the instance. When that thread exits the block, the other threads will contend for the lock, and one by one each thread will fall through the block and create a new instance of our class. So we are right back where we started.
private static MySingleton INSTANCE;
public static MySingleton getInstance() {
if (INSTANCE == null) {
synchronized(MySingleton.class) {
if (INSTANCE == null) {
INSTANCE = createInstance();
}
}
}
return INSTANCE;
}
Here we issue another check from inside the block. If the INSTANCE member has already been set, we’ll skip initialization. This is called double-checked locking.
This solves our problem of multiple instantiation. But once again, our solution has presented another challenge. Other threads might not “see” that the INSTANCE member has been updated. This is because of how Java optimizes memory operations.
Threads copy the original values of variables from main memory into the CPU’s cache. Changes to values are then written to, and read from, that cache. This is a feature of Java designed to optimize performance. But this creates a problem for our singleton implementation. A second thread — being processed by a different CPU or core, using a different cache — will not see the changes made by the first. This will cause the second thread to see the INSTANCE member as null forcing a new instance of our singleton to be created.
private static volatile MySingleton INSTANCE;
public static MySingleton getInstance() {
if (INSTANCE == null) {
synchronized(MySingleton.class) {
if (INSTANCE == null) {
INSTANCE = createInstance();
}
}
}
return INSTANCE;
}
We solve this by using the volatile keyword on the declaration of the INSTANCE member. This will tell the compiler to always read from, and write to, main memory, and not the CPU cache.
But this simple change comes at a cost. Because we are bypassing the CPU cache, we will take a performance hit each time we operate on the volatile INSTANCE member — which we do four times. We double-check existence (1 and 2), set the value (3), and then return the value (4). One could argue that this path is the fringe case as we only create the instance during the first call of the method. Perhaps a performance hit on creation is tolerable. But even our main use-case, reads, will operate on the volatile member twice. Once to check existence, and again to return its value.
private static volatile MySingleton INSTANCE;
public static MySingleton getInstance() {
MySingleton result = INSTANCE;
if (result == null) {
synchronized(MySingleton.class) {
result = INSTANCE;
if (result == null) {
INSTANCE = result = createInstance();
}
}
}
return result;
}
Since the performance hit is due to operating directly on the volatile member, let’s set a local variable to the value of the volatile and operate on the local variable instead. This will decrease the number of times we operate on the volatile, thereby reclaiming some of our lost performance. Note that we have to set our local variable again when we enter the synchronized block. This ensures it is up to date with any changes that occurred while we were waiting for the lock.
I wrote an article about this recently. Deconstructing The Singleton. You can find more information on these examples and an example of the "holder" pattern there. There is also a real-world example showcasing the double-checked volatile approach.

I use the Spring Framework to manage my singletons.
It doesn't enforce the "singleton-ness" of the class (which you can't really do anyway if there are multiple class loaders involved), but it provides a really easy way to build and configure different factories for creating different types of objects.

Wikipedia has some examples of singletons, also in Java. The Java 5 implementation looks pretty complete, and is thread-safe (double-checked locking applied).

Version 1:
public class MySingleton {
private static MySingleton instance = null;
private MySingleton() {}
public static synchronized MySingleton getInstance() {
if(instance == null) {
instance = new MySingleton();
}
return instance;
}
}
Lazy loading, thread safe with blocking, low performance because of synchronized.
Version 2:
public class MySingleton {
private MySingleton() {}
private static class MySingletonHolder {
public final static MySingleton instance = new MySingleton();
}
public static MySingleton getInstance() {
return MySingletonHolder.instance;
}
}
Lazy loading, thread safe with non-blocking, high performance.

If you do not need lazy loading then simply try:
public class Singleton {
private final static Singleton INSTANCE = new Singleton();
private Singleton() {}
public static Singleton getInstance() { return Singleton.INSTANCE; }
protected Object clone() {
throw new CloneNotSupportedException();
}
}
If you want lazy loading and you want your singleton to be thread-safe, try the double-checking pattern:
public class Singleton {
private static Singleton instance = null;
private Singleton() {}
public static Singleton getInstance() {
if(null == instance) {
synchronized(Singleton.class) {
if(null == instance) {
instance = new Singleton();
}
}
}
return instance;
}
protected Object clone() {
throw new CloneNotSupportedException();
}
}
As the double checking pattern is not guaranteed to work (due to some issue with compilers, I don't know anything more about that), you could also try to synchronize the whole getInstance-method or create a registry for all your singletons.

I would say an enum singleton.
Singleton using an enum in Java is generally a way to declare an enum singleton. An enum singleton may contain instance variables and instance methods. For simplicity's sake, also note that if you are using any instance method then you need to ensure thread safety of that method if at all it affects the state of object.
The use of an enum is very easy to implement and has no drawbacks regarding serializable objects, which have to be circumvented in the other ways.
/**
* Singleton pattern example using a Java Enum
*/
public enum Singleton {
INSTANCE;
public void execute (String arg) {
// Perform operation here
}
}
You can access it by Singleton.INSTANCE, and it is much easier than calling the getInstance() method on Singleton.
1.12 Serialization of Enum Constants
Enum constants are serialized differently than ordinary serializable or externalizable objects. The serialized form of an enum constant consists solely of its name; field values of the constant are not present in the form. To serialize an enum constant, ObjectOutputStream writes the value returned by the enum constant's name method. To deserialize an enum constant, ObjectInputStream reads the constant name from the stream; the deserialized constant is then obtained by calling the java.lang.Enum.valueOf method, passing the constant's enum type along with the received constant name as arguments. Like other serializable or externalizable objects, enum constants can function as the targets of back references appearing subsequently in the serialization stream.
The process by which enum constants are serialized cannot be customized: any class-specific writeObject, readObject, readObjectNoData, writeReplace, and readResolve methods defined by enum types are ignored during serialization and deserialization. Similarly, any serialPersistentFields or serialVersionUID field declarations are also ignored--all enum types have a fixed serialVersionUID of 0L. Documenting serializable fields and data for enum types is unnecessary, since there is no variation in the type of data sent.
Quoted from Oracle documentation
Another problem with conventional Singletons are that once you implement the Serializable interface, they no longer remain singleton because the readObject() method always return a new instance, like a constructor in Java. This can be avoided by using readResolve() and discarding the newly created instance by replacing with a singleton like below:
// readResolve to prevent another instance of Singleton
private Object readResolve(){
return INSTANCE;
}
This can become even more complex if your singleton class maintains state, as you need to make them transient, but with in an enum singleton, serialization is guaranteed by the JVM.
Good Read
Singleton Pattern
Enums, Singletons and Deserialization
Double-checked locking and the Singleton pattern

There are four ways to create a singleton in Java.
Eager initialization singleton
public class Test {
private static final Test test = new Test();
private Test() {
}
public static Test getTest() {
return test;
}
}
Lazy initialization singleton (thread safe)
public class Test {
private static volatile Test test;
private Test() {
}
public static Test getTest() {
if(test == null) {
synchronized(Test.class) {
if(test == null) {
test = new Test();
}
}
}
return test;
}
}
Bill Pugh singleton with holder pattern (preferably the best one)
public class Test {
private Test() {
}
private static class TestHolder {
private static final Test test = new Test();
}
public static Test getInstance() {
return TestHolder.test;
}
}
Enum singleton
public enum MySingleton {
INSTANCE;
private MySingleton() {
System.out.println("Here");
}
}

This is how to implement a simple singleton:
public class Singleton {
// It must be static and final to prevent later modification
private static final Singleton INSTANCE = new Singleton();
/** The constructor must be private to prevent external instantiation */
private Singleton(){}
/** The public static method allowing to get the instance */
public static Singleton getInstance() {
return INSTANCE;
}
}
This is how to properly lazy create your singleton:
public class Singleton {
// The constructor must be private to prevent external instantiation
private Singleton(){}
/** The public static method allowing to get the instance */
public static Singleton getInstance() {
return SingletonHolder.INSTANCE;
}
/**
* The static inner class responsible for creating your instance only on demand,
* because the static fields of a class are only initialized when the class
* is explicitly called and a class initialization is synchronized such that only
* one thread can perform it, this rule is also applicable to inner static class
* So here INSTANCE will be created only when SingletonHolder.INSTANCE
* will be called
*/
private static class SingletonHolder {
private static final Singleton INSTANCE = new Singleton();
}
}

You need the double-checking idiom if you need to load the instance variable of a class lazily. If you need to load a static variable or a singleton lazily, you need the initialization on demand holder idiom.
In addition, if the singleton needs to be serializable, all other fields need to be transient and readResolve() method needs to be implemented in order to maintain the singleton object invariant. Otherwise, each time the object is deserialized, a new instance of the object will be created. What readResolve() does is replace the new object read by readObject(), which forced that new object to be garbage collected as there is no variable referring to it.
public static final INSTANCE == ....
private Object readResolve() {
return INSTANCE; // Original singleton instance.
}

Various ways to make a singleton object:
As per Joshua Bloch - Enum would be the best.
You can use double check locking also.
Even an inner static class can be used.

Enum singleton
The simplest way to implement a singleton that is thread-safe is using an Enum:
public enum SingletonEnum {
INSTANCE;
public void doSomething(){
System.out.println("This is a singleton");
}
}
This code works since the introduction of Enum in Java 1.5
Double checked locking
If you want to code a “classic” singleton that works in a multithreaded environment (starting from Java 1.5) you should use this one.
public class Singleton {
private static volatile Singleton instance = null;
private Singleton() {
}
public static Singleton getInstance() {
if (instance == null) {
synchronized (Singleton.class){
if (instance == null) {
instance = new Singleton();
}
}
}
return instance;
}
}
This is not thread-safe before 1.5 because the implementation of the volatile keyword was different.
Early loading singleton (works even before Java 1.5)
This implementation instantiates the singleton when the class is loaded and provides thread safety.
public class Singleton {
private static final Singleton instance = new Singleton();
private Singleton() {
}
public static Singleton getInstance() {
return instance;
}
public void doSomething(){
System.out.println("This is a singleton");
}
}

For JSE 5.0 and above, take the Enum approach. Otherwise, use the static singleton holder approach ((a lazy loading approach described by Bill Pugh). The latter solution is also thread-safe without requiring special language constructs (i.e., volatile or synchronized).

Another argument often used against singletons is their testability problems. Singletons are not easily mockable for testing purposes. If this turns out to be a problem, I like to make the following slight modification:
public class SingletonImpl {
private static SingletonImpl instance;
public static SingletonImpl getInstance() {
if (instance == null) {
instance = new SingletonImpl();
}
return instance;
}
public static void setInstance(SingletonImpl impl) {
instance = impl;
}
public void a() {
System.out.println("Default Method");
}
}
The added setInstance method allows setting a mockup implementation of the singleton class during testing:
public class SingletonMock extends SingletonImpl {
#Override
public void a() {
System.out.println("Mock Method");
}
}
This also works with early initialization approaches:
public class SingletonImpl {
private static final SingletonImpl instance = new SingletonImpl();
private static SingletonImpl alt;
public static void setInstance(SingletonImpl inst) {
alt = inst;
}
public static SingletonImpl getInstance() {
if (alt != null) {
return alt;
}
return instance;
}
public void a() {
System.out.println("Default Method");
}
}
public class SingletonMock extends SingletonImpl {
#Override
public void a() {
System.out.println("Mock Method");
}
}
This has the drawback of exposing this functionality to the normal application too. Other developers working on that code could be tempted to use the ´setInstance´ method to alter a specific function and thus changing the whole application behaviour, and therefore this method should contain at least a good warning in its javadoc.
Still, for the possibility of mockup-testing (when needed), this code exposure may be an acceptable price to pay.

Simplest singleton class:
public class Singleton {
private static Singleton singleInstance = new Singleton();
private Singleton() {}
public static Singleton getSingleInstance() {
return singleInstance;
}
}

Have a look at this post.
Examples of GoF Design Patterns in Java's core libraries
From the best answer's "Singleton" section,
Singleton (recognizeable by creational methods returning the same instance (usually of itself) everytime)
java.lang.Runtime#getRuntime()
java.awt.Desktop#getDesktop()
java.lang.System#getSecurityManager()
You can also learn the example of Singleton from Java native classes themselves.

The best singleton pattern I've ever seen uses the Supplier interface.
It's generic and reusable
It supports lazy initialization
It's only synchronized until it has been initialized, then the blocking supplier is replaced with a non-blocking supplier.
See below:
public class Singleton<T> implements Supplier<T> {
private boolean initialized;
private Supplier<T> singletonSupplier;
public Singleton(T singletonValue) {
this.singletonSupplier = () -> singletonValue;
}
public Singleton(Supplier<T> supplier) {
this.singletonSupplier = () -> {
// The initial supplier is temporary; it will be replaced after initialization
synchronized (supplier) {
if (!initialized) {
T singletonValue = supplier.get();
// Now that the singleton value has been initialized,
// replace the blocking supplier with a non-blocking supplier
singletonSupplier = () -> singletonValue;
initialized = true;
}
return singletonSupplier.get();
}
};
}
#Override
public T get() {
return singletonSupplier.get();
}
}

I still think after Java 1.5, enum is the best available singleton implementation available as it also ensures that, even in the multi threaded environments, only one instance is created.
public enum Singleton {
INSTANCE;
}
And you are done!

Sometimes a simple "static Foo foo = new Foo();" is not enough. Just think of some basic data insertion you want to do.
On the other hand you would have to synchronize any method that instantiates the singleton variable as such. Synchronisation is not bad as such, but it can lead to performance issues or locking (in very very rare situations using this example. The solution is
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;
}
}
Now what happens? The class is loaded via the class loader. Directly after the class was interpreted from a byte Array, the VM executes the static { } - block. that's the whole secret: The static-block is only called once, the time the given class (name) of the given package is loaded by this one class loader.

public class Singleton {
private static final Singleton INSTANCE = new Singleton();
private Singleton() {
if (INSTANCE != null)
throw new IllegalStateException(“Already instantiated...”);
}
public synchronized static Singleton getInstance() {
return INSTANCE;
}
}
As we have added the Synchronized keyword before getInstance, we have avoided the race condition in the case when two threads call the getInstance at the same time.

We Keep Coding

Java is a programming language and computing platform first released by Sun Microsystems in 1995.

How do you create and later access an application level resource? - java

Edit: I am trying to create a shared database connection pool for all sessions of a web application. A different post said the best way to create a servlet context object was by having the init listener create it. I am however unclear on how to make this object available for use by my servlet.

Related

Can anyone help me with the Singleton in java [duplicate]

Is this implementation of singleton thread safe, serialization problem free and performant?

Creating many objects using composition when the containing class is a singleton pattern

Is this a valid way to ensure only a single instance of an object exists in Java?

What is an efficient way to implement a singleton pattern in Java? [closed]

Categories

Resources