It is known that statics is not tied to an object (instance), but is stored in an object type (!), And this statics is corresponding (in the form of fields / methods, etc.) will exist in a single instance for all created objects of type.

In other words, all created objects of a static class will refer to a single version of these static methods / fields.

Against this background, the question arises, what is the best way to use statics , because objects with the static modifier are not subject to garbage collection, since stored in the object type (which in turn is associated with the application domain, and will exist until the end of the application life cycle).

Should I avoid static collections / arrays that work with a large amount of data (or should it be, but will need to be "cleaned manually")?

What is a bad ton for using statics?

Or you can use statics in the same amount as the copy options?

  • slightly incorrect wording, object (instance) cannot have static modifier. This modifier may have a field that contains a reference to the object. So this object can also be deleted by GC if we remove the link to it from the static field. So there is no problem using statics in this context. But forgetting to link to heavy objects in static fields can be elementary in order to leak memory. - rdorn
  • @rdorn "slightly incorrect wording, object (instance) cannot have static modifier." - that you here again confuse. Statics can not be removed from the GC, re-read my post carefully. - CSharpUser
  • besides, static is almost harmless, compared to delegates and lamdas, in terms of leaks, not to mention unmanaged resources, and plug-in native libraries, which themselves sometimes leak. - rdorn
  • fields and methods cannot be deleted, yes. The type object will hang in memory from the first call to the unload domain. But the array type field does not contain the array itself, but only a link to it is rdorn
  • Of course there is one evil option, declare a static field with a huge structure inside, but this is targeted sabotage =) - rdorn

1 answer 1

I think that it is necessary to be guided not by “physical” storage features, but by semantics, the meaning of your data.

If you have any method or data for all instances of the class, then this method / data should be declared static. If you, for example, have an instance in the singular in the system, then you should declare it a singleton.

This should be the main consideration for how you declare your data. If in your program, in its meaning, the data are static, declare them static. If they are essentially an instance, declare them as instance data.

Example: the color of a car produced by the concern Henry Ford is black . So this is static data:

 class FordCar { public static readonly Color = Colors.Black; }

In my company there is currently only one car. But it is still a specific instance. So this is singleton :

 class OurCompanyCar { private OurCompanyCar() { } public static OurCompanyCar() Instance { get { return lazy.Value; } } private static readonly Lazy<OurCompanyCar> lazy = new Lazy<OurCompanyCar>(() => new OurCompanyCar()); }
  • Thank you, agree. But nevertheless I dare to object, namely, the moment that the “meaning of the data”, at a minimum, must be based (based) on how this whole thing will be stored in memory, in order to avoid leaks, etc. In general, statics is not a panacea, and it should be used wisely and in small doses. - CSharpUser
  • 2
    @CSharpUser should not. - Pavel Mayorov
  • 2
    @CSharpUser if the data is required all the time - then they will have to be stored permanently, no matter how you organize the storage. - Pavel Mayorov
  • @PavelMayorov and how caching? (With further saving in memory, and the return process). It does not always make sense to keep everything in memory. :) - CSharpUser
  • one
    @CSharpUser is cached data and does not have semantics of constants. - Pavel Mayorov