Lifetime of Static Classes and Variables

[Chuck Cobb]

I am creating some static classes with static methods and static variables,
but I have a question: What is the lifetime of static classes and static
variables? Is there any risk that these items might be garbage collected
if they're not used for a period of time?

For example:

public static class test
{
static Collection<string> coll;

public static void AddItem()
{
coll = new Collection<string>();
coll.Add("abc");
}

public static string GetItem(int index)
{
return coll[index];
}
}

Suppose I call the AddItem method and nothing is holding a reference to this
class, what's to prevent it from being garbage collected and destroyed?

Do static members like this live for the life of the application without
being subject to garbage collection?

Thanks,

Chuck Cobb

 

[the.duckman]

Is this net 2.0 version of .NET?

On my version (1.1) static can not be used to describe a class.

On my version of .NET I find static members static members live for the
duration of the application.

I can't realy imagine a circumstance where a GC could act on static
data, Ithink th GC does not go there at all and the memory is release
only on application closure.

I'd be looking to use a singleton pattern rather then have a static
collection.

-dm

 

[Jon Skeet [C# MVP]]

I am creating some static classes with static methods and static variables,
but I have a question: What is the lifetime of static classes and static
variables? Is there any risk that these items might be garbage collected
if they're not used for a period of time?

Static variables exist for the lifetime of the ApplicationDomain they
live in.

 

[the.duckman]

You got my curiosity going,

I sniffed around and found this excelent article by Matthew Cochran.

http://www.c-sharpcorner.com/Upload...rticleID=411a0c5c-a0f6-4de2-8a17-e861d5aecd87

It actuly has your exact problem in it (towards the end) and shows a
little memory problem that might occur with the way you have set up
your class (not the one you were worried about though).

Infact the other sections of the article make for good reading as well.

-dm

 

[David Levine]

Static methods are not objects that are subject to garbage collection, so
they have no lifetime issues for you to deal with.

For each static field there is one copy per-appdomain - each appdomain can
have a different value. The static variable itself is not garbage
collected - it is just a memory location that contains a reference to an
object. Static fields are considered to be GC roots, so any references in
them will not be garbage collected as long as the field contains that
reference. If you change the field to point to a new reference or set the
field value to null then the object whose reference was stored there becomes
eligible for collection.

Static class constructors will run once for each appdomain they get loaded
in.

Per your example, the method AddItem() is not an object that can get
garbage collected, it is a method. Each time you call AddItem a new
Collection object will be allocated and its reference assigned to the field
coll. Any previous reference stored in that field will be eligible for
garbage collection, but the current reference will not be GCd.

 

[Jon Skeet [C# MVP]]

You got my curiosity going,

I sniffed around and found this excelent article by Matthew Cochran.

http://www.c-sharpcorner.com/Upload...rticleID=411a0c5c-a0f6-4de2-8a17-e861d5aecd87

It actuly has your exact problem in it (towards the end) and shows a
little memory problem that might occur with the way you have set up
your class (not the one you were worried about though).

Infact the other sections of the article make for good reading as well.

It's unfortunately inaccurate in terms of methods and memory, implying
that each object carries around its own copy of all the instance
methods for that type. I'll add a comment to that effect...

Jon

 

[Jon Skeet [C# MVP]]

It's unfortunately inaccurate in terms of methods and memory, implying
that each object carries around its own copy of all the instance
methods for that type. I'll add a comment to that effect...

Grr... I would have added a comment, but their login seems to be
totally broken

Jon

 

[Marcus Andrén]

You got my curiosity going,

I sniffed around and found this excelent article by Matthew Cochran.

http://www.c-sharpcorner.com/Upload...rticleID=411a0c5c-a0f6-4de2-8a17-e861d5aecd87

It actuly has your exact problem in it (towards the end) and shows a
little memory problem that might occur with the way you have set up
your class (not the one you were worried about though).

Infact the other sections of the article make for good reading as well.

-dm

The author of that article has some serious misunderstandings when
trying to explain methods. A misunderstanding that unfortunally seems
very common. It tries to put to much information about methods on the
heap.

Ordinary methods doesn't actually have any data at all on either the
stack or the heap. It is all stored in the code section. The only
exception is virtual/abstract methods that keep one V-Table on the
heap for each class.

So, how does method calling work? First it should be noted that static
methods and instance methods work exactly the same.

instance.Method(5);

is the same as

Method(instance,5);

It is only when virtual methods and inheritance that it becomes a
little more complicated. When calling a virtual method, code has to
look at the instance which contains a pointer to its class. It will
then look into the V-Table to find out which method to call.

To answer the original poster. Static variables are stored once for
each class and lives until the application ends. Static classes
doesn't have anything special compared to normal classes, except for
not having a default public constructor.

 

[Chuck Cobb]

Thanks! This has been a good discussion and was very helpful....

Chuck Cobb

 

[the.duckman]

Marcus,

Thanks, I handn't picked up on the articles problem (skim reader)... I
might take a look at it again later.

Anyway I stilll don't like the idea of static collections... I personly
would use a singleton for what its worth. if nothing else it allows the
colection to be stored properly if ths class to be serialized.


-dm


-dm