Why is Singleton considered an anti-pattern?

I wouldn't exactly consider singleton to be an anti-pattern.

However, a singleton is basically a way to use global variables. And global variables are bad because any code anywhere in the system can change their values. So when debugging, it can be challenging to figure out which code path leads to the Singleton's current state.

To help with answering, here is more about the anti-pattern comment:

it is overused, introduces unnecessary restrictions in situations where a sole instance of a class is not actually required, and introduces global state into an application

From: http://en.wikipedia.org/wiki/Singleton_pattern

For more on this you can look at: https://www.michaelsafyan.com/tech/design/patterns/singleton

Here is a great ending to the blog above:

In short, the singleton pattern makes code more complex, less useful, and a real pain to re-use or test. Eliminating singletons can be tricky, but it’s a worthwhile endeavour.

OK, so, the reason it is an anti-pattern is described well in this paragraph, and, as the author expresses, it tightly couples your code to the singleton.

If you find that you want to use a singleton, you may want to consider your design, but there are times where it is useful.

For example, once I had to write an application that could have at most one database connection, to process thousands of requests. So, a singleton makes sense since I am resource constrained to having only one instance.

But, generally this is used to simplify code, without thinking of the difficulties that will be introduced.

For example, and this applies to static classes also, if you unit test, or have concurrency, then the state of one request will change the state and that may cause problems, as the class calling the instance may be assuming the state is as it expected.

I think the best way to challenge the use is to think of how to handle it if your program is multi-threaded, and a simple way to do that is to unit test it, if you have several tests that run at one time.

If you find that you still need it, then use it, but realize the problems that will be encountered later.

Singletons are often badly implemented. See double-checked-locking.

In which scope must an Singleton instance be unique. Like multi-Threaded environments, clustering etc.

Singletons can be hard to test.

Memory allocated to an Singleton can't be freed.

With excessiv usage of singletons you leave from objectoriented programming to procedural programming.

I think it is considered an anti-pattern because a Singleton class can't be instantiated in a normal way by other object (except by calling such method commonly named "getInstance"). So, it will look like the class is being used directly without instantiating it to create a usable object first.

I agree with you that Singleton can serve as a global unique instance. I learned from some people that as alternatives for Singleton, we can use static and/or final variables, and we can also use enumeration (so that we can group multiple variables under one group name as what we usually do when we are working using a normal class/object).

However, these alternatives can only match the capability of a Singleton class in storing states/values. If we need unique functions to work with, those static/final variables and enumerations cannot help. In my opinion, this is the case when we need to use a Singleton class (when we need some unique functions to work with static/final states/values).

Cheers... :))