Some of these circumstances have to do with the quirks of special class loaders, multithreading, distributed systems, and object serialization, which makes them all the harder to figure out when they do occur. In this article, Joshua Fox explains how to watch out for those pitfalls and how to avoid the oxymoronic multiple singleton. In this article, I'll show you how that can happen and how to avoid it. The singleton's purpose is to control object creation, limiting the number to one but allowing the flexibility to create more objects if the situation changes. Since there is only one singleton instance, any instance fields of a singleton will occur only once per class, just like static fields.
Singletons often control access to resources such as database connections or sockets.
For example, if you have a license for only one connection for your database or your JDBC driver has trouble with multithreading, the singleton makes sure that only one connection is made or that only one thread can access the connection at a time. If you add database connections or use a JDBC driver that allows multithreading, the singleton can be easily adjusted to allow more connections. On the other hand, singletons can also be stateless, providing utility functions that need no more information than their parameters. In that case, there is no need to instantiate multiple objects that have no reason for their existence, and so a singleton is appropriate. However, in certain situations, two or more singletons can mysteriously materialize, disrupting the very guarantees that the singleton is meant to provide.