With Singleton there will be only one instance of the class per jvm. Most often application specific things can go in singleton. For Ex: if you want to design an application such that application_state (can have values idle, active, on maintenance) need to be shared with many users you can keep this variable in a singleton class.
Advantages are by making a heavy weight class singleton, you are sharing a single instance of that class with many threads. This will save you resources and time.
There isn't an advantage, which is why the singleton is becoming more widely known as the "singleton antipattern", as the design pattern hype subsides. First and foremost, a singleton does not exist, without solid proof of a finite universe, which we don't have. A singleton can exist within a given context; for example, a class loader, a JVM, many JVMs. In practice, I see most singletons implemented throughout a class loader, which is as simple as a global point of access to a hidden static field.
The singleton is usually implemented to prevent the need to pass a callback to clients. Specifically, some state can be updated in a singleton from one point in the application (or more correctly, the singleton context), and can be observed by another point, without either point knowing about each other (though indirectly through the singleton). This pattern can be traced to a requirement defect within a given context - one that we often assume. Since the notion of "design patterns" is losing the spotlight among the newer marketing hype, it is becoming more widely known that behind the gloss, is the opposite of what it was originally portraying itself as. Prefer to pass the callback type, and don't believe the hype - that rhymes I should approach a record label. </geekiness>