Does using a static member inside a non-static method cause memory leakage?

Question

Does the DoSomething() method cause memory leakage?

public static class AppContext
{
   public static int ApplicationStateId {get; set} 
   ...
} 
public class MyService
{
     public void DoSomething()
     {
        ....
        if(AppContext.ApplicationStateId == 1) 
        {
             //do something
        } 
     }
}

var service = new MyService();
service.DoSomething();

This means that static variables and everything they reference will never be garbage collected.

Michael said in 8 Ways You can Cause Memory Leaks in .NET.

Its not a memory leak, but it is persistent until the process dies. A memory leak is when you create something and then never free its memory after not using it anymore. — John, Jul 14 '20 at 10:13
Static member are [not garbage collected](https://stackoverflow.com/q/6600093/1997232), so they are potential reasons of memory leak (e.g. static events, singletons/instance holders, etc.). In your example, it's just `int`, which is value type, so no, that can't be a reason of leak. — Sinatr, Jul 14 '20 at 10:19
@John: does `service` free by GC after using it? or freeing `service` delayed until application ends? — Masoud, Jul 14 '20 at 10:49
MyService will free whenever its scope ends, such as at the end of a function. AppContext will continue to exist. — John, Jul 14 '20 at 10:53
(Note that a variable's scope has no relation to when it might be collected. Variables that are still in scope can be collected, if they're not used beyond that point) — canton7, Jul 14 '20 at 10:58

score 5 · Accepted Answer · answered Jul 14 '20 at 10:17

There is no "leak" here; this is simply the expected behavior. Yes, anything that is reachable via a static field will will not be collected by GC, but this is usually correct in terms of some kind of global state. By "leak", we're usually referring to unexpected or inexplicable memory retention. The most common scenario there is with static events which sound like a great idea, but make it very easy to keep entire segments of long-redundant objects alive. For example:

SomeType.SomeStaticEvent += obj.HandleTheThing;

which now means that the object from obj is now retained forever (or at least until the delegate is explicitly removed from the event), and anything that obj can see: is now retained forever, etc.

In the case shown in the question, there aren't even any objects - just an integer. I don't think you need to worry about the cost of retaining an integer over the duration of an app-domain, especially if your app-domain requires that integer to be known for the duration.

I'd be more concerned about things like concurrency - whether that means "multiple current user stations", or low level details like volatility and register usage of fields.

Thank you, I used `CurrentUserStationId` to explain my question, you are right, I changed the `CurrentUserStationId` to `ApplicationStateId`:) — Masoud, Jul 14 '20 at 10:36

Does using a static member inside a non-static method cause memory leakage?

1 Answers1