I recently deep dive into java. in Java 7 "static variable" and "static method" are stored in "method area" but since Java 8 I saw this sentence in JVM specification
The proposed implementation will allocate class meta-data in native memory and move interned Strings and class statics to the Java heap
Some article says static variables, static class can't be deleted by Garbage Collector and Some say vice versa.(Since Java8 static class, static variables is in heap memory)
I'm so confused right now.
In conclusion, where static method, static variables, static class is stored in java8?
FYI
public class Example {
public static int staticInt = 5; // <- static variable
public static class StaticInnerExample { //<- static class
}
public static void hello() { // <- static method
System.out.println("hello");
}
}
All code is held in metaspace.
All class metadata is held in metaspace.
All static variables are held in the heap.
So:
In conclusion, where static method, static variables, static class is stored in java8?
The answers are 1) metaspace, and 2) heap. For 3) it depends on what you mean. However the metadata is the only aspect of a static class that has a representation, and that is stored in metaspace.
Note that an application cannot get its hands on the actual method code, class metadata or frame containing the static variables.
Also note that class metadata, method code, and static frames not copied when (for example) objects are created.
So it is moot where they are actually stored.
Some article says static variables, static class can't be deleted by Garbage Collector.
Those articles are incorrect ... if that is what they actually say. The reality is that a class may be garbage collected if it becomes unreachable, but it is not easy to create the conditions in which a class becomes unreachable. So, in practice classes are rarely garbage collected.
Likewise, a classes static variables will become unreachable if the class itself is unreachable. But that is rare too; see above.
But anyway, the logical inference you were trying to make is incorrect. Being in the heap is neither necessary or sufficient for something to be reclaimed by one of the JVM's storage management mechanisms.