This question already has an answer here:
Closed 10 years ago.
Possible Duplicate:
static allocation in java - heap, stack and permanent generation
its a small confusion...defining static to class, methods and variables.In this three cases where thus the memory allocated. ? My boss is familiar with C,he says only variables are in heap memory and rest (static classes and static methods) will remain in main memory. is that ture? any explanation.?
one more
in android using static class and static methods is a best practice ?
Try this,
static members are stored in Method Area.
Class instances and arrays are stored in heap memory. Heap memory is also called as shared memory. As this is the place where multiple threads will share the same data.
Non-heap Memory
It comprises of ‘Method Area’ and other memory required for internal processing. So here the major player is ‘Method Area’.
Method Area
As given in the last line, method area is part of non-heap memory( A special heap area). It stores per-class structures, code for methods and constructors. Per-class structure means runtime constants and static fields.
The above three (heap memory, non-heap memory and method area) are the main jargon when it comes to memory and JVM.
Class instances and arrays are stored in heap memory. Heap memory is also called as shared memory. As this is the place where multiple threads will share the same data.
Static variables are saved in the same place as the Classes declaration (methods and attributes, etc). 1). Classes (loaded by the classloaders) go in a special area on heap called Permanent Generation, and static field too go to the same place as they are common to each instance of the class.
For more details :
see this answer
Related
I heard that there are non-static and static areas in JVM memory in a lecture course, but I can't find any information about the two areas of the method area of JVM memory.
Do non-static and static areas exist in the method area?
I think they must be because when the program needs some non-static method, JVM has to load the method on the non-static area of the method area and it has to be efficiently deleted if the non-static method is not used anymore by heap area or stack area.
I think you might be conflating storage requirements for methods (code) and fields (data).
Non-static fields are represented in the heap node of each object that has those fields. Naturally, when the object is deleted, all of its fields go away as well.
Static fields are represented in (typically) a heap node that is associated with the class that declares the fields. Normally, this node lives for the lifetime of the JVM. However, if the associated class is unloaded, then the node is (notionally) eligible for garbage collection.
Whether the former and latter nodes are in the same area of the heap is ... implementation-dependent.
I suspect that this is what the lecture was talking about. (However, it is not entirely clear without actually seeing/hearing what the lecture material says.
Are there non-static and static areas in the method area of JVM memory?
Basically, no.
The memory that holds the code of methods is associated with the class and has the same lifetime1 as the class (see above). Therefore the code for static and non-static (instance) methods can be (and is) stored the same way.
The area in which the code is stored is also implementation-dependent. However, for recent JVMs methods are held in metaspace ... which is not strictly part of the Java heap.
A final note: you don't need to know the precise details of this unless you are or plan to be an OpenJDK developer. And if you do need (or want) to know the precise details ... look at the source code. But beware that it could take you weeks to get your head around it, depending on how experienced you are with this kind of thing.
1 - This is an oversimplification. In some contexts, the JIT compiler may recompile native code. When that happens, the JVM will reallocate the memory blocks that hold a method's native code. However, it is all taken care of ...
If I create a static variable in Java, does it automatically go into the perm gen space on the heap? it seems obvious that the answer is yes, but i cannot find the confirmation anywhere.
I know the static variable (also strings and enums) are alive for the life of the JVM so it must go on the permanent heap. IS this correct?
The idea of the "PermGen" is completely implementation-dependent, and JVMs are free to handle the "physical" memory management however makes sense to them--they're not even actually required to provide garbage collection!
The PermGen is just a feature of some JVM implementations (including the Sun/Oracle HotSpot JVM for many years), and it's actually being eliminated with a new approach in the Oracle Java 8 JVM. It's quite likely that JVMs that include the concept of a PermGen will put static variables there for performance, but it's entirely up to the programmer.
JLS #17.4.1 Shared Variables
Memory that can be shared between threads is called shared memory or heap memory.
All instance fields, static fields and array elements are stored in heap memory. In this chapter, we use the term variable to refer to both fields and array elements. Local variables (§14.4), formal method parameters (§8.4.1) or exception handler parameters are never shared between threads and are unaffected by the memory model.
Nice description here By #Stephen:static allocation in java - heap, stack and permanent generation
I am trying to fully understand how the Java works with its memory arrangement. The discussions on Internet are very confused, and sometimes contradicts each other, so I found no one I can trust. This thing can be very complicate if it mixed with static, static method, local variable, thread, volatile and so on. So I am thinking if there is a way I can study that myself my doing some Java coding experiment. A class MemoryTrack does something like this,
public myMethod(){
int i = 0;
MemoryTrack.show(new myClass()); //print out "Heap at address 111"
MemoryTrack.show(new myClass()); //print out "Heap at address 222"
MemoryTrack.show(i); //print out "Stack at address 333"
MemoryTrack.show("a static method"); //print out "stack at address 444"
}
The use of memory is described in Section 2.5 of the Java Virtual Machine Specification. The stack stores stack frames (containing local variables and partial results). The heap is where all class instances and arrays come from. Stack frames can also be allocated from the heap (and then pushed onto the stack). There are also method areas and runtime constant pool memory. The details are spelled out in the spec.
As far as monitoring memory usage, several profilers have tools for that. For monitoring from within the program, take a look at the MemoryMXBean class (and related classes in the java.lang.management package). It's very easy to use. While it probably doesn't give you everything that it sounds like you want, but it's probably the best thing available.
The rule is pretty simple: heap contains objects, stack contains local variables and method parameters. Object fields are inside the objects, in the heap. Don't know about static fields. Methods and constructors are not stored in the stack, nor in the heap. Threads and volatile don't matter.
Method calls are on the stack. Each has a space reserved to it, the stack frame, that contains the local variables and the parameters.
Two things you need to know
its not as complicated as you think.
it doesn't matter 99% of the time.
Variables are always on the stack.
Objects are always on the heap. (There are exceptions but I wouldn't worry about them)
Methods and classes are always in the perm gen.
In the HotSpot/OpenJDK JVM, static fields are collected in a singleton object for the class. You can see the instance if you do a heap dump. Other JVMs may do this differently.
A class MemoryTrack does something like this,
Such a method wouldn't do anything useful as the argument will always be on the stack and object it refers to will always be on the heap. You can't get the memory location of an Object in a standard way and it unlikely to be useful if it did as it can change at any time.
You may think all variables in Java are on heap. Actually it is implementation dependent.
We have two classifications heap and stack . When a object is created, memory for object is stored in heap. What if the class has static methods ,which can be called using class name. If object is not created then how will it allocate memory and if it does where will it allocate memory?
It depends on the JVM, but static fields are usually stored in a special object on the heap. (You can see it in a heap dump) When the ClassLoader is unloaded, its classes and their static "objects"/fields are also cleaned up.
The only thing different about the static "object" is you can't get a reference to it. (But you can use reflection to access the fields)
Methods (i.e., code) aren't stored in an object; all objects of a class will share the code for a method. Regardless of language (Java, C++, or virtually anything else) there will be only a single copy of the code for any method, static or not. Generally there's a specific area of memory -- i.e., a CODE segment in a native language like C++, or a special heap area in Java -- where code is loaded.
Permanent Generation(PermGen) space of heap contain permanent class
metadata and descriptors information.
PermGen space always reserved for classes and those that are tied to
the classes(Static members, static functions, etc...)
Static function belongs to the class so they can be called to without
creating the object of the class.
This is a follow-up question to How are static arrays stored in Java memory? .
So global variables in C/C++ are stored in the static data segment of memory. But what about static class variables in Java/C++?
It can't be the static data segment because you don't know what/how many classes are going to be referenced throughout the duration of your program (because of reflection). It's definitely not the stack because that makes no sense. Storing it on the heap is also kind of iffy.
In Java, at a low level, class static variables are indeed stored on the heap, along with all other class metadata. To Java, they look like globals, but to the JVM's low level heap management routines, they're dynamic data (although they may be treated slightly specially in order to improve GC efficiency, since they're likely to be long lived). After all, classes can be unloaded by unreferencing their classloader.
As for whether it's the same as the C malloc(), not likely. Most JVMs take control of their heaps at a low level; they grab a chunk of memory from the OS and divvy it up themselves. As such, most Java data, including static data, are not stored in the malloc heap, but rather in a separate heap managed by the JVM.
Java has a "permanent" heap where it puts class metadata. So the "roots" of the static values are in the permanent heap. The values are reference values (class objects) the values themselves are in the regular heap.
Static variables will not be stored in Heap.. They are part of Data Segment.
Local variables will be stored in - Stack;
Instance variables will be stored in - Heap;
Class variables(Static) will be stored in - Data Segment. These variables will be shared across all objects of that class..
Your final machine equivalent java code will be stored in - Code/text segment.