The memory managed by the Java VIRTUAL machine is divided into the program counter, Java virtual machine stack, local method stack, Java heap, and method area
- Thread sharing: method area, Java heap; Thread private: Java virtual machine stack, local method stack, program counter
Program counter
Multithreading in the Java Virtual Machine works by switching between threads in turn, allocating execution time to processors so that at any given time, one processor (or, in the case of multi-core processors, one core) is executing instructions from only one thread. Each thread has a separate program counter that records where the program was executed so that it can be found when the thread is switched and executed again. The program counters of each thread do not affect each other and are stored independently.
The characteristics of
- The only area where OutOfMemoryError (memory overflow) does not occur;
- The program counter is created together with the thread when it is created and the corresponding memory is allocated.
- If the thread is executing a Java method, the counter records the address of the vm bytecode instruction being executed. If the thread is executing a Native method, the counter is null (Undefined).
- Threads are private, and each thread corresponds to a program counter.
Java virtual machine stack
Threads are private and have the same life cycle as threads. The thread memory model for Java method execution is described: When each method is executed, a stack frame is created in the Java virtual machine to store information about local variables, operand stack, dynamic connections, method exits, and so on. Each method that is called to the finished process corresponds to a stack frame in the virtual stack count from the stack to the stack.
- If a thread requests a stack depth greater than the vm allows, a StackOverflowError exception is raised. If the Java virtual machine stack is dynamically scalable (HotSpot virtual machine is not scalable, Classic virtual machine is scalable), then an OutOfMemoryError(Memory overflow) exception will be thrown when the stack cannot be allocated enough memory.
Local variable scale
- It stores the various basic Java VIRTUAL machine data types known at compile time (byte, char, short, int, float, long, double, Boolean), object references, and the returnAddress type (which points to the address of a bytecode instruction). The storage space of these data types in the local variable table is represented by local variable slots; There are two slots for 64-bit long and double data, and one for the rest.
- The size of the local variable table is fully allocated during compilation. When entering a method, how much local variable space the method needs to allocate in the stack frame is completely determined. The size of the local variable table does not change during the run of the method. How much memory space is used by the virtual machine (1 variable slot takes 32 bits, 64 bits… …). To implement a slot of variables, determined by the virtual machine.
Local method stack
The local method stack is similar to the VIRTUAL machine stack. The difference is that the virtual machine stack serves the Java methods (bytecode) executed by the VM, while the local method stack serves the local methods used by the VM. The HotSpot virtual machine combines the local method stack with the virtual machine stack. StackOverFlowError and OutOfMemoryError also occur.
The Java heap
The Java Heap is the largest chunk of memory managed by a virtual machine. Shared by all threads and created when the VM starts. Unique function: Stores object instances. The Java Virtual Machine Specification describes the heap: all object instances and arrays should be allocated on the heap. The Java heap is an area of memory managed by the garbage collector, so some data is also referred to as the “GC heap.” The Java heap can be implemented as either fixed-size or extensible, and the current mainstream Java virtual machine is implemented as extensible (with the -xmx and -xms parameters). The Java virtual machine throws OutOfMemeryError if there is no memory in the Java heap for instance allocation and the heap is no longer growing.
Methods area
An area of memory shared by threads that stores data such as type information, constants, static variables, and code caches compiled by just-in-time compilers that have been loaded by virtual machines. An OutOfMemeryError exception occurs. The Java Virtual Machine Specification is very loose on the method area, and in addition to not requiring continuous memory like the Java heap and having the option of being either fixed size or scalable, you can even opt out of garbage collection.
To add information about static variables:
- There are two kinds of member variables in a Java class: variables that are modified by the static keyword, called class or static variables; Member variable with no static modifier;
- The Java Virtual Machine allocates memory for static variables during class loading. Static variables reside in the method area and are shared by all instances of the class. Static variables can be accessed directly by the class name, and their lifetime depends on the lifetime of the class;
- Instance variables depend on the instance of the class. Each time an instance is created, the Java VIRTUAL Machine allocates memory for instance variables, which reside in the heap and whose lifetime depends on the lifetime of the instance.
- The order of initialization in JAVA: load the class; Static variable initialization; Static block; Member variable; Construction method;
Runtime constant pool
Part of the method area. This is used to store the various literal and symbolic references generated at compile time, which are stored in the run-time constant pool in the method area after class loading. An OutOfMemeryError exception occurs.