11

I understand the lifetime of static variables in relation to applications (console/windows) but I'm not sure if I am understanding their lifetime when in the context of web apps (asp.net, mvc, web api, etc).

From what I understand, when IIS recycles the app pool, static variables are reset to their type's defaults (integrals = 0, reference types = null, etc), but I'm wondering if inline initializers are re-initialized after recycles or will the type defaults ALWAYS be assigned regardless?

Example(s):

// example 1
static class StaticRandom
{
    private static Random rng = new Random();
}

In the above, would the static field rng be reinitialized to new Random() when called for the first time after a recycle? Or do I need to implement null checks before attempting to use the variable, such as:

// example 2
static class StaticRandom
{
    private static Random rng = null;

    public static Next()
    {
        if (rng == null)
            rng = new Random();
        return rng.Next();
    }
}

Am I correct in assuming that after an IIS recycle, the rng variable in example 1 would be null until reinitialized like in example 2?

NOTE: I'm fully aware of the thread safety issues in the above example, it's just a quick example to illustrate my question. In a real-world scenario of the above idea, I would implement a proper locking pattern.

Mike Johnson
  • 686
  • 5
  • 13
  • This wouldn't be such a hard thing to try out yourself. Put a breakpoint in the `Next` method for example 1 and see what you've got as the value for `rng` following a recycle. – Jon Egerton Dec 19 '13 at 00:18
  • 1
    I figured it'd be a lot easier to just ask for clarification rather than loading my local server and twiddling my thumbs for 15 mins while I wait for it to enter a recycle lol. Besides, sometimes people include little gotcha's to keep in mind which are nice to know. – Mike Johnson Dec 19 '13 at 00:20
  • 4
    "wait for it to enter a recycle": Open IIS and recycle the app pool yourself? – Jon Egerton Dec 19 '13 at 00:21
  • lol zing! It's been a long day... – Mike Johnson Dec 19 '13 at 00:22
  • lol - I'm in the UK - work out what time it is here!! ;-) – Jon Egerton Dec 19 '13 at 00:23
  • Could someone elaborate on the `I'm fully aware of the thread safety issues in the above example` note? Whats the proper locking pattern, or what kind of resource could I look up to learn more about this? Thanks! – Zorgarath Oct 02 '15 at 16:41
  • @Zorgarath The problem is that two threads could enter the Next method simultaneously before it's initialized, then thread A checks if rng is null, which is true, and before it can asign a new instance, thread B checks if rng is null which is still true, which will result in one of the two overwriting the rng instance. A simple lock statement would suffice there. This is a good resource to learn synchronization techniques: http://www.cs.mtu.edu/~shene/NSF-3/e-Book/index.html – andyroschy Feb 03 '16 at 16:15

1 Answers1

7

Ok, so couldn't help myself, and did a quick test.

This was pretty much as per your example 1, except with a page output so I could do it without being attached to the process,

It confirmed what I thought - The static will be reset to the inline initialize value.

Jon Egerton
  • 40,401
  • 11
  • 97
  • 129