A colleague of mine told me that I should never use static variables because if you change them in one place, they are changed everywhere. He told me that instead of using static variables I should use Singleton. I know that Singleton is for limitation of the number of instances of one class to one. How can Singleton help me with static variables?
-
3That's the _point_ of static fields. Also, singetons _are_ static fields (but readonly). Your friend sounds wrong. – SLaks Nov 01 '11 at 15:25
-
12When someone says "never" or "always," they're usually wrong especially when referencing a feature of the language itself. – Austin Salonen Nov 01 '11 at 15:26
-
Okay, but can you answer the question? – petko_stankoski Nov 01 '11 at 15:26
-
Static could be helpful - depends on what are you trying to achieve. Ask your colleague if statics is evil why .NET Framework does not get rid of them yet? Good example `Extension Methods` which actively uses statics – sll Nov 01 '11 at 15:27
-
Oddly enough even if you change a variable held in a Singleton, it is still going to change "everywhere", so what is he talking about? – Adam Houldsworth Nov 01 '11 at 15:27
-
1The purpose of a static variable is to maintain state across a class rather then be associated with an actual object or a member of the class. So I don't understand what your friend is talking about - there are many cases where you should / have to use static fields. – JonH Nov 01 '11 at 15:27
-
1If the foundation of the question is invalid, is the question still valid? – Austin Salonen Nov 01 '11 at 15:27
-
@sll: That's not a good argument. There are lots of evil things, such as mutable structs, that are still in .Net. – SLaks Nov 01 '11 at 15:28
-
@user966638 - we'll answer the question if you could ask us what to answer. You are giving us an opinion not a question. – JonH Nov 01 '11 at 15:28
-
@AdamHouldsworth: Singletons should be immutable. – SLaks Nov 01 '11 at 15:28
-
@SLaks Not bothered... refer to the question for the solution given by "the colleague" for not using statics... lol – Adam Houldsworth Nov 01 '11 at 15:28
-
8I would be intrigued to know how your colleague intends to implement the singleton pattern *without* using a static field. – Jon Skeet Nov 01 '11 at 15:32
-
My question is how to avoid static variables with Singleton? – petko_stankoski Nov 01 '11 at 15:33
-
2I think your colleague is guiding you towards turning static fields or properties into member fields or properties of a class, and then holding a singleton instance of that class. So those fields/properties themselves are not static, but the instance is a singleton, which by nature would be rooted in a static field at the source. But without you showing code with an actual problem or without having your colleague here, we can't say for certain what the two of you are talking about. – Anthony Pegram Nov 01 '11 at 15:39
-
1But keep in mind, whether you modify static fields/properties or the fields/properties of a single instance, anything that sees that singleton instance will also see those modifications. Both approaches are global state. If observed mutations are what your colleague wants to avoid, then neither approach applies. – Anthony Pegram Nov 01 '11 at 15:41
-
@AnthonyPegram I think you're right. – petko_stankoski Nov 01 '11 at 15:45
-
Your colleague is correct (if you use statics like they did in VB6), however his suggestion to fix his concerns by using a singleton is laughable. By definition, a singleton is a static instance, accessible anywhere, and when someone changes its state, it changes everywhere. – Nov 01 '11 at 15:54
-
@petko_stankoski Could you please read [my answer](http://stackoverflow.com/a/43596186/57611) and let me know if you have any more clarity on what your coworker meant? I realize you posted this question 5 1/2 years ago, so perhaps you've forgotten by now. However, I could really use your help in clarifying the past confusion (which my answer should help you do) so that this question/answer page can best serve future visitors to it. – ErikE Apr 24 '17 at 21:50
6 Answers
Let's address your statements one at a time:
A colleague of mine told me that I should never use static variables because if you change them in one place, they are changed everywhere.
It seems fairly clear that your colleague means the basic feature of static variables: there is only one instance of a static variable. No matter how many instances of any class you create, any access to a static variable is to the same variable. There is not a separate variable for each instance.
He told me that instead of using static variables I should use Singleton.
This is not good global advice. Static variables and singletons aren't in competition with each other and aren't really substitutes for each other. A singleton is an instance of a class, managed in such a way that only one instance is possible to create. A static variable is similarly tied to exactly one (static) instance of a class, but could be assigned with not only a class instance but any data type such as a scalar. In actuality, to effectively use the singleton pattern, you must store it in a static variable. There is no way to "use a singleton instead of a static variable".
On the other hand, perhaps he meant something slightly different: perhaps he was trying to say that instead of your static class having many different static variables, methods, properties, and fields (altogether, members) that function as if they were a class, you should make those fields non-static, and then expose the wrapping class as a Singleton instance. You would still need a private static field with a method or property (or perhaps just use a get-only property) to expose the singleton.
I know that Singleton is for limitation of the number of instances of one class to one. How can Singleton help me with static variables?
A static class's variables and a singleton are alike in that they both are instantiated once (the former enforced by the compiler and the latter enforced by your implementation). The reason you'd want to use a singleton instead of a static variable inside of a class is when your singleton needs to be a true instance of a class, and not consist simply of the collected static members of a static class. This singleton then gets assigned to a static variable so that all callers can acquire a copy of that same instance. As I said above, you can convert all the different static members of your static class to be instance members of your new non-static class which you will expose as a singleton.
I would also like to mention that the other answers given so far all have issues around thread safety. Below are some correct patterns for managing Singletons.
Below, you can see that an instance of the Singleton
class, which has instance (or non-static) members, is created either by static initialization or within the static constructor, and is assigned to the variable _singleton
.. We use this pattern to ensure that it is instantiated only once. Then, the static method Instance
provides read-only access to the backing field variable, which contains our one, and only one, instance of Singleton
.
public class Singleton {
// static members
private static readonly Singleton _singleton = new Singleton();
public static Singleton Instance => _singleton
// instance members
private Singleton() { } // private so no one else can accidentally create an instance
public string Gorp { get; set; }
}
or, the exact same thing but with an explicit static constructor:
public class Singleton {
// static members
private static readonly Singleton _singleton; // instead of here, you can...
static Singleton() {
_singleton = new Singleton(); // do it here
}
public static Singleton Instance => _singleton;
// instance members
private Singleton() { } // private so no one else can accidentally create an instance
public string Gorp { get; set; }
}
You could also use a property default without an explicit backing field (below) or in a static constructor can assign the get-only property (not shown).
public class Singleton {
// static members
public static Singleton Instance { get; } = new Singleton();
// instance members
private Singleton() { } // private so no one else can accidentally create an instance
public string Gorp { get; set; }
}
Since static constructors are guaranteed to run exactly once, whether implicit or explicit, then there are no thread safety issues. Note that any access to the Singleton
class can trigger static initialization, even reflection-type access.
You can think of static members of a class as almost like a separate, though conjoined, class:
Instance (non-static) members function like a normal class. They don't live until you perform
new Class()
on them. Each time you donew
, you get a new instance. Instance members have access to all static members, including private members (in the same class).Static members are like members of a separate, special instance of the class that you cannot explicitly create using
new
. Inside this class, only static members can be accessed or set. There is an implicit or explicit static constructor which .Net runs at the time of first access (just like the class instance, only you don't explicitly create it, it's created when needed). Static members of a class can be accessed by any other class at any time, in or out of an instance, though respecting access modifiers such asinternal
orprivate
.

- 48,881
- 23
- 151
- 196
-
The question isn't asking how to create a singleton. This isn't addressing the actual question asked at all. – Servy Apr 24 '17 at 20:00
-
You shouldn't be posting an answer to say that the question doesn't make sense. If you think that the question doesn't make sense, vote to close it as unclear, rather than posting an answer to a question you don't think is understandable. – Servy Apr 24 '17 at 21:06
-
@Servy The question as written doesn't make sense, however the asker's confusion is easy to understand and easily correctable. Do you have a resource on meta.stackexchange that supports your position that "the question doesn't make sense as written"? In any case, I will reword to say that the asker's statements make some invalid assumptions, which I can help correct for him. – ErikE Apr 24 '17 at 21:07
-
I don't need to prove to you that the question doesn't make sense. *You* are the one saying that the question doesn't make sense, both in your answer (on *multiple* occasions) and in your comment. – Servy Apr 24 '17 at 21:10
-
@Servy I wasn't asking you to prove that the question doesn't make sense. I was *trying* to ask you why your opinion that "you shouldn't post an answer to say a question doesn't make sense" conforms to community standards in the stackexchange network and on stackoverflow specifically (as I've never heard that before). In any case, I have removed all references to "this doesn't make sense", and in fact, have to thank you for your push-back as I think my answer is now improved--I think I've now hit on the most likely advice the colleague was trying to give and explained how to do that. – ErikE Apr 24 '17 at 21:15
-
You really need me to explain to you why you shouldn't answer a question that doesn't make sense? There's a *specific* close reason for questions that don't make sense, "Unclear what you're asking". When it's unclear what a question is asking, you should use that close reason. While you've re-worded your answer, you're still indicating that the question is unclear by saying that you find the question confusing, that you're having to guess at what it's asking, etc. – Servy Apr 24 '17 at 21:19
-
I changed my mind. I think the question makes sense now. And I think the question and answer add value, even if the original asker wasn't 100% clear. He was still 80% clear, and explaining the difference between `static` and a singleton should clear up any confusion. – ErikE Apr 24 '17 at 21:22
-
1@Servy Are you going to vote down the other answers on the page that have the same problems mine do (in your mind)? Is there a reason you singled out my answer above the others besides that it is a new answer? If you think the question is that unclear, you can cast your vote to close, right? – ErikE Apr 24 '17 at 21:24
EDIT @ErikE's response is the correct approach.
For thread safety, the field should be initialized thusly:
private static readonly Singleton instance = new Singleton();
One way to use a singleton (lifted from http://msdn.microsoft.com/en-us/library/ff650316.aspx)
using System;
public class Singleton
{
private static Singleton instance;
private Singleton() {}
public static Singleton Instance
{
get
{
if (instance == null)
{
instance = new Singleton();
}
return instance;
}
}
/// non-static members
public string Foo { get; set; }
}
Then,
var foo = Singleton.Instance.Foo;
Singleton.Instance.Foo = "Potential thread collision here.";
Note that the instance member is a static field. You can't implement a singleton without using a static variable, and (I seem to recall - it's been awhile) this instance will be shared across all requests. Because of that, it's inherently not thread safe.
Instead, consider putting these values in a database or other persistent store that's more thread-friendly, and creating a class that interfaces with that portion of your database to provide transparent access.
public static class Foo
{
public static string Bar
{
get { /// retrieve Bar from the db }
set { /// update Bar in the db }
}
}

- 28,657
- 18
- 88
- 151
-
Except, can't you get thread safety by assigning the `instance` variable with a static initializer: `private static readonly Singleton instance = new Singleton()`? Then your property can just be: `public static Instance => instance;`. The only difference is that `instance` is assigned the first time the `Singleton` class is used in *any* capacity, not the first time `Instance` is accessed. This is a minor detail, as any problems this causes can be eliminated by moving the code to its own class so any access to the class does occur only when the singleton can be instantiated. – ErikE Apr 24 '17 at 19:07
-
I just confirmed that static initializers are *guaranteed* to run only once per app domain (be careful with static generics though as that's once per generic type). So using a static method instead of a static initializer or static constructor is not a good idea as it brings with it the non-thread-safe problems you mention. – ErikE Apr 24 '17 at 19:15
-
Yup, I did notice. So now, my comment helps all those people who come to this question looking for current answers, instead of leaving them in the obsolete/archaic land of trying to use old code on new frameworks! It's a win all around, right? I didn't down-vote you. It was good information for the time. – ErikE Apr 25 '17 at 01:47
-
1If you like I'll delete and reword to avoid saying "not a good idea" and can say instead "there is now a better way that avoids all thread safety issues". – ErikE Apr 25 '17 at 01:49
The whole point of the static
modifier is to ensure that the object thus modified is the same wherever it is used as it requires no instantiation. The name originally came about as a static variable has a fixed location in memory and all items referring to it will reference the same memory location.
Now you may wish to use a static field within a class, in which case it exists before the class is instantiated (constructed). There may be instances where you would want this.
A singleton is a different beast. It is a class that is limited to a single instantiation by use of a private constructor and a static
property. So in that regard you still can't avoid statics by using a singleton.

- 9,104
- 3
- 22
- 35
-
Static fields don't exist before a class is created. But you can be sure that it exists before any *instance* of that class is created. – svick Nov 01 '11 at 15:38
-
-
You say it exists “before the class is instantiated (constructed)”. I think that's confusing. Classes aren't instantiated, objects that are an instance of the class are. – svick Nov 01 '11 at 16:09
-
My apologies I thought that by saying "(constructed)" after instantiated that I'd made it clear that a static field exists before a class contructor is executed. – ChrisBD Nov 01 '11 at 16:15
-
And that's confusing again. What's a “class constructor”? It could be interpreted as static constructor or instance constructor. Although, you would be right in both cases. – svick Nov 01 '11 at 16:18
-
Well what can I say? In practice does it make any difference? The static constructor is only executed once for a given application domain, whereas the class instance constructor may be executed many times, eitherway the static field exists and is initialized before either of the constructors are executed. – ChrisBD Nov 01 '11 at 16:42
To answer the stated question:
It is incredibly stupid (but possible) to create a singleton without a static field.
To do it, you need to use someone else's static field, such as AppDomain.GetData
or (in ASP.Net) HttpContext.Application
.

- 868,454
- 176
- 1,908
- 1,964
-
I agree with SLaks above. Read this post from a previous question: [Design Patterns When to Use the Singleton](http://stackoverflow.com/questions/228164/on-design-patterns-when-to-use-the-singleton/228380#228380) – ninu Nov 01 '11 at 15:34
Just to answer your question (I hope): Instead of using a static class containing static members like Class1 you can implement the Singleton pattern like in Class2 (please don't begin a discussion about lazy initialization at this point):
public static class Class1
{
public static void DoSomething ()
{
}
}
public static class Class2
{
private Class2() {
}
private Class2 instance;
public Class2 GetInstance(){
if (instance == null)
instance = new Class2();
return instance;
}
public void DoSomething ()
{
}
}
Instead of calling Class1.DoSomething()
you can use Class2.GetInstance().DoSomething()
.
Edit: As you can see there's still a (private) static field inside Class2 holding it's instance.
Edit2 in answer to user966638's comment: Do I understand you correct that you have code like this:
public class Foo {
private static Bar bar;
}
And your collegue suggests to replace it by this?
public class Foo {
private BarSingleton bar;
}
This could be the case if you want to have different Foo instances where each instance's bar attribute could be set to null for example. But I'm not sure if he meant this what exactly is the use case he is talking about.

- 1,140
- 11
- 12
-
And can you explain how does that help alleviate the “problems” static classes have? Also, your code won't compile, I assume you didn't intend to make `Class2` `static`. – svick Nov 01 '11 at 15:41
-
But the initial class wasn't static. It was normal class which contains methods and variables. Some of the variables are static. – petko_stankoski Nov 01 '11 at 15:42
-
-
The `GetInstance` method here is not thread-safe and could yield multiple instances of the same class, because another thread's execution of `GetInstance` could also check that `instance == null` before either thread sets `instance` to `new Class2()`. Best to use static initialization instead of trying to sychronize, which is full of pitfalls. – ErikE Aug 25 '20 at 17:40
Both singleton and static variables give you one instance of a class. Why you should prefer singleton over static is
- With Singleton you can manage the lifetime of the instance yourself, they way you want
- With Singleton, you have greater control over the initialization of the instance. This useful when initializing an instance of a class is complicated affair.
- It's challenging to make static variables thread-safe, with singleton, that task becomes very easy
Hope this helps

- 7,919
- 5
- 34
- 54
-
4
-
That's not true at all. You can't manage the lifetime of a singleton. Singletons do not help you achieve thread safety. All of your claims (true or not) also apply to static fields. – SLaks Nov 01 '11 at 15:29
-
[ThreadStaticAttribute](http://msdn.microsoft.com/en-us/library/system.threadstaticattribute.aspx) – Austin Salonen Nov 01 '11 at 15:29
-
@JonH A static field or property still holds a single instance as its value. – Steve Rowbotham Nov 01 '11 at 15:31
-
@SteveRowbotham that I can agree with- I was more describing a `static class` more then a static member of a class which has one value...ack ambiguity. – JonH Nov 01 '11 at 15:33
-
@SteveRowbotham: Wrong. A property does not hold a single instance; it can return whatever it wants. A field can be `[ThreadStatic]` – SLaks Nov 01 '11 at 15:33
-
1@SLaks: `[ThreadStatic]` isn't under discussion. The point I was making is straight-forward - whether you expose a static field directly or via a property there is still an instance. – Steve Rowbotham Nov 01 '11 at 15:38
-
@jonh There has to be some instance at the core, isn't it? And I was talking more from perspective of control you have over the static as against a singleton. – Suhas Nov 01 '11 at 16:46