What is the actual memory place for static variables?

Question

A static variable is allocated for the entire duration of a program's execution, so neither stack nor heap are convenient for it. Then where is that variable? Shouldn't there be some place where it is loaded from?

Solution 1

Static fields are initialised when a class is loaded and are discarded when the classloader for that class is unloaded. They can be cleaned up, even duplicated in another class loader.

For applications like those that use OSGi, static variables don't live for the whole life of the application. They can be reloaded many times.

How this is implement may be JVM dependent, but the Sun/Oracle JVM creates an "object" to hold the static fields for a class. This object is accessible via the Unsafe class which can also be used to examine this "objects" fields.

Solution 2

We have 3 segments in our memory:

1. Stack Segment — contains local variables and Reference variables (variables that hold the address of an object in the heap).

2. Heap Segment — contains all created objects in runtime, objects only plus their object attributes (instance variables).

3. Code Segment — the segment where the actual compiled Java bytecodes resides when loaded. Static members (variables or methods) are called class members, meaning they reside where the class (bytecode) resides, which is in the Code Segment.

Solution 3

Static variable is allocated for the entire duration of program's execution, so neither stack nor heap are convenient for it.

In fact, static frames (i.e. the frames that hold the static variables) ARE allocated from the heap.

And they don't necessarily exist for the duration of a program's execution. For instance, static frames for classes that are dynamically loaded can be garbage collected if the parent classloader, all classes and all instances becomes unreachable.

Solution 4

Out of five memory areas that JVM uses, the static fields are allocated memory in Class Area(part of PremGen) when the class is loaded by the Application class loader during prepare and loading phase. If the field is primitive, the value is stored in the class area and if it is of Object type (new operator used), it is stored in heap but the reference is given to the assigned static field variable in class area. When the class is unloaded, the memory for that static field is also available to be garbage collected by GC.

If the field is final as well, that is, static final, it is kept in constant pool under class area.

Solution 5

From http://www.daniweb.com/software-development/java/threads/34695:

Static variable's memory is allocated at the start of the program, in regular memory, instead of the stack (memory set aside specifically for the program). the advantage of this is that it makes your variable or procedure totally constant, and you can't accidentally change the value. the disadvantage of this is that the memory is not deallocated until the program is terminated. I have never heard anything that static values take any more memory than if they are declared regularly, but thier memory use is constant throught.

View more solutions

Comments

[Oliver Charlesworth]

-1: "Totally constant"? Are you thinking of final? And memory not being deallocated until the end; that's not a disadvantage, that's the whole point of static!

[Pacerier]

@OliCharlesworth, He's talking about static final variables. And being forced to use more memory for a longer period of time is a disadvantage compared to not having to do that.

[ravindrab]

this answer is up voted so much, but contradicts with stackoverflow.com/questions/3849634/…

[galeop]

Sourav, can you give your sources please ?

[flow2k]

Perhaps Sourav is referring to C++?

[David Torrey]

This answer explains how static variables work but doesn't explain the actual question of how the memory is managed