The Singleton Pattern is one of the most important Java design patterns and is frequently asked in interviews. It ensures that only one instance of a class is created and provides a global point of access to that instance.
Below are Singleton Pattern interview questions from Q11 to Q15 with exact answers and explanations.
Q1. Imagine you are developing a logging utility for an application that should have only one logging instance throughout the application lifecycle. The application runs in a multithreaded environment. Which approach of the Singleton Pattern should be the best fit to avoid synchronization overhead and ensure thread safety?
Options:
- A) Double-Checked Locking
- B) Synchronized Method
- C) Holder Class (Bill Pugh Method)
- D) Enum Singleton
Answer:
C) Holder Class (Bill Pugh Method)
Explanation:
- A) Double-Checked Locking: Incorrect. While it does reduce synchronization overhead, double-checked locking is more complex and can still have some edge cases if not implemented carefully.
- B) Synchronized Method: Incorrect. Synchronizing the entire method can lead to performance bottlenecks in a high-concurrency environment.
- C) Holder Class (Bill Pugh Method): Correct. The Holder Class method uses a static inner class, providing a clean and efficient thread-safe Singleton without explicit synchronization.
- D) Enum Singleton: Incorrect. Although effective, Enum Singleton is often overkill for most cases and is less flexible compared to the Holder Class method.
Q2. What technique should be used in a Singleton class to prevent multiple instances from being created when the object is serialized and then deserialized?
Options:
- A) Implement a private constructor
- B) Mark the instance variable as volatile
- C) Implement the readResolve method
- D) Use double-checked locking
Answer:
C) Implement the readResolve method
Explanation:
- A) Private constructor: Incorrect. While it restricts instantiation from outside the class, it doesn’t prevent multiple instances created through deserialization.
- B) Marking instance as volatile: Incorrect. This helps with visibility in a multithreaded environment but does not address serialization issues.
- C) readResolve method: Correct. Implementing readResolve ensures that upon deserialization, the existing instance is returned, maintaining the Singleton guarantee.
- D) Double-checked locking: Incorrect. Double-checked locking is a thread-safety mechanism for lazy initialization but does not prevent Singleton violations due to deserialization.
Q3. Which of the following conclusion is correct on the below Singleton implementation?
public class Singleton {
private static Singleton instance;
private Singleton() { }
public static synchronized Singleton getInstance() {
if(instance == null) {
instance = new Singleton();
}
return instance;
}
}
Options:
- A) This implementation is thread-safe and efficient due to synchronization.
- B) This implementation is not thread-safe because of potential race conditions.
- C) This implementation is thread-safe but may cause performance issues in high-concurrency environments.
- D) This implementation is unsafe for multithreading and should be changed to a static block.
Answer:
C) This implementation is thread-safe but may cause performance issues in high-concurrency environments.
Explanation:
- A) Thread-safe and efficient due to synchronization: Incorrect. While the synchronized method is thread-safe, it can become a bottleneck in high-concurrency scenarios because only one thread can access it at a time.
- B) Not thread-safe due to race conditions: Incorrect. Synchronization in getInstance prevents race conditions, ensuring thread safety.
- C) Thread-safe but may cause performance issues: Correct. Synchronizing the entire method limits access, potentially slowing performance if many threads call getInstance simultaneously.
- D) Unsafe and requires a static block: Incorrect. A static block is unnecessary; synchronization here is sufficient for thread safety.
Q4. Consider the following code snippet. Which statement is correct about this implementation?
public class Singleton {
private static final Singleton instance = new Singleton();
private Singleton() {}
public static Singleton getInstance() {
return instance;
}
}
Options:
- A) This is a correct implementation of an eager-initialized, thread-safe Singleton.
- B) This implementation is thread-unsafe because it does not synchronize getInstance.
- C) This implementation is lazy-loaded, so it won’t work in multithreaded environments.
- D) This Singleton implementation is incorrect because it allows multiple instances through reflection.
Answer:
A) This is a correct implementation of an eager-initialized, thread-safe Singleton.
Explanation:
- A) This is a correct implementation of an eager-initialized, thread-safe Singleton: Correct. Eager initialization creates the instance when the class loads, ensuring thread safety without additional synchronization.
- B) Thread-unsafe due to lack of synchronization: Incorrect. Since eager initialization creates the instance immediately, synchronization in getInstance is unnecessary.
- C) Lazy-loaded and unsuitable for multithreading: Incorrect. Eager initialization means the instance is created at load time, not lazily.
- D) Incorrect due to reflection vulnerability: Incorrect. While reflection can indeed break Singleton, this does not invalidate the pattern itself.
Q5. Consider a Singleton class that uses eager initialization. Which of the following approaches can help prevent the Singleton instance from being created multiple times through reflection?
Statements:
- Implementing a check inside the constructor to throw an exception if the instance is already created.
- Using synchronized blocks to control instantiation.
- Marking the instance final.
- Using Enum Singleton.
Options:
- A) Statements 1 & 2
- B) Statements 1 & 4
- C) Statements 3 & 4
- D) All statements are correct
Answer:
B) Statements 1 & 4
Explanation:
- Statement 1: Correct. Adding a check inside the constructor to throw an exception on additional instance creation can help control Singleton violations through reflection.
- Statement 2: Incorrect. Synchronization alone cannot prevent reflection-based instantiation.
- Statement 3: Incorrect. Marking the instance as final does not prevent reflection attacks from creating new instances.
- Statement 4: Correct. Enum Singleton is inherently protected against reflection violations, making it an ideal choice.
Visited 2 times, 2 visit(s) today
