The "trick" with singleton is to not over-use it. A common mistake in application design comes from thinking "gee, I don't think I'll ever bother creating more than one of these, so I guess I should use singleton". The whole point of singleton isn't just that you only see yourself using one instance. It is that fundamentally your app would be broken if you tried to use more than one instance, and that the implementation of that instance could vary (e.g. by subclassing or creating multiple implementations of an interface).
Objects representing external resources like your operating system services (java.lang.Runtime) or windowing environment, or sometimes an object creation factory tend to make for good examples of using singleton effectively. Karthi's example of Logger is a good example, particularly if you think in terms of the Jakarta commons logging API instead of Log4J. It isn't the Logger instance itself which is the singleton, it is really the logging implementation behind it that is the true singleton. The implementation could be Log4J or Sun's logging API or something else. By changing the configuration of commons logging, all your code would get a new logging environment without any code change. [ January 19, 2006: Message edited by: Reid M. Pinchback ]