Saturday, December 20, 2014

Java Singleton Design Pattern Interview Questions


Java Singleton Design Pattern Best Practices with Examples
Singleton using Enum in Java
public enum EasySingleton{
    INSTANCE;
}

Enum Singletons handled Serialization by themselves


Creation of Enum instance is thread-safe
As stated in point 1 since creatino of Enum instance is thread-safe by default you don't need to worry about double checked locking.
Eager initialization
Static block initialization ==> to handle exception during initialization
https://hellosmallworld123.wordpress.com/2014/07/28/singleton-object-design-pattern/
Static class:
Only nested classes can be static. By doing so you can use the nested class without having an instance of the outer class. a static class must have all its members static. It is different from singleton
https://hellosmallworld123.wordpress.com/2014/05/21/threads-and-locks/
try finally ?
public class singleton {
    singleton s;
    Lock lock = new ReentrantLock(); // lock
    private singleton() {} // override the default constructor.
    public singleton getInstance() {
            lock.lock();
            if (s == null)
                s = new singleton();
            lock.unlock();
        }
    }
}
Lazy Initialization
Double-Checked Locking (DCL) idiom
http://stackoverflow.com/questions/1879283/different-ways-to-write-singleton-in-java
tatic volatile Singleton instance;

public static Singleton getInstance() {
  if (instance == null) {
    synchronized (Singleton.class) {
      if (instance == null)
        instance == new Singleton();
    }
  }
  return instance;
}
Or
static Singleton instance;

public static synchronized Singleton getInstance() {
  if (instance == null)
    instance == new Singleton();
  return instance;
}
Using volatile keyword to define singleton with double checked locking. The reason we use volatile keyword is because we want it to be visible to all the other thread as soon as the instance is updated.

the double checked locking helps improve efficiency with the first lock (because it checks if instance is null or not before entering the synchronized block so that if eliminates the overhead of doing checking after the singleton is initialized. While the second check makes sure that creation of the instance is atomic.

nitialization on Demand Holder (IODH) idiom
requires very little code and has zero synchronization overhead. Zero, as in even faster than volatile. IODH requires the same number of lines of code as plain old synchronization, and it's faster than DCL!

IODH utilizes lazy class initialization. The JVM won't execute a class's static initializer until you actually touch something in the class. This applies to static nested classes, too. In the following example, the JLS guarantees the JVM will not initialize instance until someone calls getInstance():
static class SingletonHolder {
  static Singleton instance = new Singleton();    
}

public static Singleton getInstance() {
  return SingletonHolder.instance;
}
http://javarevisited.blogspot.sg/2011/03/10-interview-questions-on-singleton.html
8) How do you prevent for creating another instance of Singleton using reflection?
Open to all. In my opinion throwing exception from constructor is an option.
Answer: This is similar to previous interview question. Since constructor of Singleton class is supposed to be private it prevents creating instance of Singleton from outside but Reflection can access private fields and methods, which opens a threat of another instance. This can be avoided by throwing Exception from constructor as “Singleton already initialized”

9) How do you prevent for creating another instance of Singleton during serialization?
Another problem with conventional Singletons are that once you implement serializable interface they are no longer remain Singleton because readObject() method always return a new instance just like constructor in Java. you can avoid that by using readResolve() method and discarding newly created instance by replacing with Singeton as shwon in below example :

    //readResolve to prevent another instance of Singleton
    private Object readResolve(){
        return INSTANCE;
    }

This can become even more complex if your Singleton Class maintain state, as you need to make them transient, but witn Enum Singleton, Serialization is guarnateed by JVM.

Singleton using Enum in Java
http://javarevisited.blogspot.com/2012/07/why-enum-singleton-are-better-in-java.html
By default creation of Enum instance is thread safe but any other method on Enum is programmers responsibility.

public enum EasySingleton{
    INSTANCE;
}

2) Enum Singletons handled Serialization by themselves
Another problem with conventional Singletons are that once you implement serializable interface they are no longer remain Singleton because readObject() method always return a new instance just like constructor in Java.
  private Object readResolve(){
        return INSTANCE;
    }

3) Creation of Enum instance is thread-safe
public enum SingletonEnum {
    INSTANCE;
    public void doStuff(){
        System.out.println("Singleton using Enum");
    }
}

Singleton is one of the most common design patterns, but it has many implementation variants: lazy Instantiation, eager Instantiation, static holder idiom, and etc. Static holder idiom is my favorite.
package org.codeexample.javacode.singletons;
import java.io.Serializable;
public class SinletonVariants {
}
/**
 * When the singleton class is referenced, its instance would not be created,
 * and also Java guarantees that the class initialization is atomic.
 * 
 * So using the static holder idiom, we combine the benefit of lazy
 * instantiation and no further synchronization after the instance is created,
 * <p>
 * My favorite, always use this one.
 */
class SingletonHolderIdiom {
 private SingletonHolderIdiom() {
 }
 private static class SingletonHolder {
  private static final SingletonHolderIdiom instance = 
        new SingletonHolderIdiom();
 }
 public static SingletonHolderIdiom getInstance() {
  return SingletonHolder.instance;
 }
}
/**
 * To maintain the singleton guarantee, you have to declare all instance fields
 * transient and provide a readResolve method that directly return the static
 * instance, also you must use eager instantiation.
 * <p>
 * see Effective Java 2nd Edition: <br>
 * Item 3: Enforce the singleton property with a private constructor or an enum
 * type
 */
class SerializableSingleton implements Serializable {
 private static final long serialVersionUID = 1L;
 private static SerializableSingleton instance = new SerializableSingleton();
 private SerializableSingleton() {
 }
 public static SerializableSingleton getInstance() {
  return instance;
 }
 // readResolve method to preserve singleton property
 private Object readResolve() {
  return instance;
 }
}
/**
 * This variant avoids the drawback of eager instantiation, as no resources are
 * allocated before the instance is actually accessed, but further
 * synchronization might seem unnecessary and expensive after the instance is
 * already constructed.
 * 
 */
class SingletonLazyInstantiation {
 private static SingletonLazyInstantiation instance;
 private SingletonLazyInstantiation() {
 }
 public static synchronized SingletonLazyInstantiation getInstance() {
  if (instance == null) {
   instance = new SingletonLazyInstantiation();
  }
  return instance;
 }
}
/**
 * This would initialize this singleton class eagerly, when the class is loaded
 * at first time. Thus, it may happen that the singleton instance is constructed
 * even if it is not accessed. This is a drawback, especially when the
 * construction is complex and time/resource consuming. The good part of this
 * variant is its simplicity.
 * 
 */
class SingletonEagerInstantiation {
 private static SingletonEagerInstantiation instance = 
    new SingletonEagerInstantiation();
 private SingletonEagerInstantiation() {
 }
 public static SingletonEagerInstantiation getInstance() {
  return instance;
 }
}
Read full article from Java Singleton Design Pattern Best Practices with Examples

No comments:

Post a Comment

Labels

Review (554) System Design (293) System Design - Review (189) Java (178) Coding (75) Interview-System Design (65) Interview (60) Book Notes (59) Coding - Review (59) to-do (45) Knowledge (39) Linux (39) Interview-Java (35) Knowledge - Review (32) Database (30) Design Patterns (29) Product Architecture (28) Big Data (27) Soft Skills (27) Miscs (25) MultiThread (25) Concurrency (24) Cracking Code Interview (24) Career (22) Interview - Review (21) Java - Code (21) Operating System (21) Distributed (20) Interview Q&A (20) OOD Design (20) System Design - Practice (19) Security (17) Algorithm (15) How to Ace Interview (15) Brain Teaser (14) Google (13) Linux - Shell (13) Spark (13) Spring (13) Code Quality (12) How to (12) Interview-Database (12) Interview-Operating System (12) Redis (12) Tools (12) Architecture Principles (11) Company - LinkedIn (11) Testing (11) Resource (10) Solr (10) Amazon (9) Cache (9) Search (9) Web Dev (9) Architecture Model (8) Better Programmer (8) Company - Uber (8) Interview - MultiThread (8) Java67 (8) Math (8) OO Design principles (8) SOLID (8) Scalability (8) Cassandra (7) Git (7) Interview Corner (7) JVM (7) Java Basics (7) Machine Learning (7) NoSQL (7) C++ (6) Design (6) File System (6) Highscalability (6) How to Better (6) Kafka (6) Network (6) Restful (6) Trouble Shooting (6) CareerCup (5) Code Review (5) Company - Facebook (5) Hash (5) How to Interview (5) JDK Source Code (5) JavaScript (5) Leetcode (5) Must Known (5) Be Architect (4) Big Fata (4) C (4) Company Product Architecture (4) Data structures (4) Design Principles (4) Facebook (4) GeeksforGeeks (4) Generics (4) Google Interview (4) Hardware (4) JDK8 (4) Optimization (4) Product + Framework (4) Shopping System (4) Source Code (4) Web Service (4) node.js (4) Back-of-Envelope (3) Company - Pinterest (3) Company - Twiiter (3) Company - Twitter (3) Consistent Hash (3) GOF (3) Game Design (3) GeoHash (3) Growth (3) Guava (3) Interview-Big Data (3) Interview-Linux (3) Interview-Network (3) Java EE Patterns (3) Javarevisited (3) Map Reduce (3) Math - Probabilities (3) Performance (3) Puzzles (3) Python (3) Resource-System Desgin (3) Scala (3) UML (3) geeksquiz (3) AI (2) API Design (2) AngularJS (2) Behavior Question (2) Bugs (2) Coding Interview (2) Company - Netflix (2) Crawler (2) Cross Data Center (2) Data Structure Design (2) Database-Shard (2) Debugging (2) Docker (2) Elasticsearch (2) Garbage Collection (2) Go (2) Hadoop (2) Html (2) Interview - Soft Skills (2) Interview-Miscs (2) Interview-Web (2) JDK (2) Logging (2) POI (2) Papers (2) Programming (2) Project Practice (2) Random (2) Software Desgin (2) System Design - Feed (2) Thread Synchronization (2) Video (2) ZooKeeper (2) reddit (2) Ads (1) Advanced data structures (1) Algorithm - Review (1) Android (1) Approximate Algorithms (1) Base X (1) Bash (1) Books (1) C# (1) CSS (1) Chrome (1) Client-Side (1) Cloud (1) CodingHorror (1) Company - Yelp (1) Counter (1) DSL (1) Dead Lock (1) Difficult Puzzles (1) Distributed ALgorithm (1) Eclipse (1) Facebook Interview (1) Function Design (1) Functional (1) GoLang (1) How to Solve Problems (1) ID Generation (1) IO (1) Important (1) Internals (1) Interview - Dropbox (1) Interview - Project Experience (1) Interview Tips (1) Interview-Brain Teaser (1) Interview-How (1) Interview-Mics (1) Interview-Process (1) Jeff Dean (1) Joda (1) LeetCode - Review (1) Library (1) LinkedIn (1) LintCode (1) Mac (1) Micro-Services (1) Mini System (1) MySQL (1) Nigix (1) NonBlock (1) Process (1) Productivity (1) Program Output (1) Programcreek (1) Quora (1) RPC (1) Raft (1) RateLimiter (1) Reactive (1) Reading (1) Reading Code (1) Refactoring (1) Resource-Java (1) Resource-System Design (1) Resume (1) SQL (1) Sampling (1) Shuffle (1) Slide Window (1) Spotify (1) Stability (1) Storm (1) Summary (1) System Design - TODO (1) Tic Tac Toe (1) Time Management (1) Web Tools (1) algolist (1) corejavainterviewquestions (1) martin fowler (1) mitbbs (1)

Popular Posts