Java: Single Class — Real Use Cases & Interview Q&A
👨💼 Interviewer: Can you explain what a Singleton class is?
👨💻 Candidate:
Sure. A singleton class is a special class where only one object (instance) is ever created in the entire application. It’s mainly used when we want to share the same object across different parts of the system — for example, a logging service or a configuration manager.
👨💼 Interviewer: Okay, where have you used Singleton in your projects?
👨💻 Candidate:
I’ve used Singleton in places like:
- Central logging utility
- Application-wide configuration loader
- Database connection pool manager (though we usually use frameworks like HikariCP now)
- Cache manager (like a wrapper over Redis or in-memory cache)
👨💼 Interviewer: How do you create a singleton class in Java?
👨💻 Candidate:
There are a few ways, but the most common is eager initialization:
public class MySingleton {
private static final MySingleton INSTANCE = new MySingleton();
private MySingleton() {}
public static MySingleton getInstance() {
return INSTANCE;
}
}
This is thread-safe and simple because the instance is created at class loading time.
👨💼 Interviewer: Is this implementation thread-safe?
👨💻 Candidate:
Yes, the eager initialization version is thread-safe by default. If we need lazy initialization, then we have to be careful with synchronization.
👨💼 Interviewer: What if two threads call getInstance() at the same time?
👨💻 Candidate:
In the eager initialization approach — it’s safe. But in lazy initialization, we should use the Bill Pugh Singleton pattern which uses a static inner class:
public class MySingleton {
private MySingleton() {}
private static class Holder {
private static final MySingleton INSTANCE = new MySingleton();
}
public static MySingleton getInstance() {
return Holder.INSTANCE;
}
}
This approach is also thread-safe and supports lazy loading.
👨💼 Interviewer: What happens if we try to clone a Singleton object?
👨💻 Candidate:
Good question. Cloning can break Singleton because it creates a new object. To prevent that, we override the clone()method:
@Override
protected Object clone() throws CloneNotSupportedException {
throw new CloneNotSupportedException("Cloning not allowed for Singleton");
}
👨💼 Interviewer: Can serialization also break Singleton?
👨💻 Candidate:
Yes. During deserialization, a new object is created. To fix this, we use readResolve():
private Object readResolve() {
return getInstance();
}
This ensures that deserialization returns the same singleton instance.
👨💼 Interviewer: Nice. What’s the safest and simplest way to implement Singleton in Java?
👨💻 Candidate:
Using an enum. It solves all issues — thread safety, serialization, even reflection:
public enum MySingleton {
INSTANCE;
public void doSomething() {
// business logic
}
}
👨💼 Interviewer: Why not just use static methods then?
👨💻 Candidate:
Good point. Static methods are okay for utility-like operations. But Singleton gives us flexibility:
- We can implement interfaces
- We can lazy-load
- We can test or mock the singleton object
- We can maintain internal state
Static methods can’t do that.
👨💼 Interviewer: How do you test Singleton in unit tests?
👨💻 Candidate:
I usually check that two getInstance() calls return the same object using ==.
If needed, I use reflection to reset the singleton (but only in test cases — not recommended in prod).
👨💼 Interviewer: Final question — what mistakes should we avoid with Singleton?
👨💻 Candidate:
- Avoid using lazy initialization without synchronization
- Don’t allow cloning or serialization without protection
- Be careful of using Singleton for things that need to scale horizontally (like microservices)
- Don’t use Singleton for everything — it’s a design tool, not a rule
🔚 Summary
Singleton class is powerful but needs careful design. In interviews, don’t just show code — explain why and where it’s useful. Discuss thread safety, cloning, serialization, and real scenarios.
Leave a Reply