In Java, memory is managed by a virtual machine, and unlike C + + you need to write the appropriate Delete/free method for each object, and it is not easy to have memory leaks and memory overflow problems.
The Java Virtual machine divides the memory he manages into several different data regions as it executes the Java program, as shown in the following illustration:
Program Counter
A program counter is a small area of memory that can be viewed as the line number indicator of the bytecode executed by the current thread. Bytecode interpreter at work is the value of this counter to select the next need to execute bytecode instructions, branch, loop, jump, exception handling, thread recovery and other basic functions need this counter to complete. When multithreaded programming, in order to restore to the correct execution position after the thread switch, each thread has a program counter, that is, the program counter is not shared by all threads, and each thread's program counter does not affect each other, so this kind of memory area is called "Thread-private" memory. In addition, this memory area is the only area that does not have a outofmemoryerror condition specified in the Java Virtual Machine specification. Java Virtual machine stack
Used to say that Java memory is divided into heaps and stacks (not rigorous), where the stack refers to the Java Virtual machine stack or the virtual machine stack in the local variables table part. Virtual machine stacks are the memory models that Java methods perform, and each method creates a stack frame (stack frame) to store information such as local variable tables, operand stacks, and so on. Each method from the beginning to the end of the call corresponds to a stack frame in the virtual machine stack into the stack to the process, as a result, we can also know that Java Virtual machine stacks are also thread-private, and that the lifecycle and thread lifecycle also explain that the variables declared in the method do not have thread synchronization problems. Again, the local variable table, which holds the basic data type, object reference, and ReturnAddress type (pointing to the address of a byte-code instruction) that is known at compile time. The memory space required by a local variable table is allocated at compile time, and when a method is entered, it is known that the method needs to allocate a large number of local variable spaces in the frame, and the method does not change the size of the local variable table during operation. In the Java Virtual Machine specification, two exceptions are specified for this area: if the thread requests a stack depth greater than the virtual machine allows, it throws a Stackoverflowerror exception, and if the virtual machine stack can be dynamically extended, Throws a outofmemoryerror when it cannot be extended. Local Method Stack
The local method stack plays a very similar role to the virtual machine stack, where virtual machine stacks perform Java method services for virtual machines, and the local method stack performs native method services for virtual machines and is also thread-private. The language, methods, and data structures used in the local method stack are not mandatory in the virtual machine specification, so the specific virtual machine is free to implement it. Like the virtual machine stack, it throws Stackoverflowerror and OutOfMemoryError. Java Heap
The heap is the largest piece of memory managed by a virtual machine, and unlike several areas mentioned above, it is not a thread-private, but a memory area shared by all threads, as described in the Java Virtual Machine specification: All object instances and arrays are allocated on the heap. However, with the development of JIT compiler and the maturity of escape analysis technology, stack allocation, scalar substitution optimization technology will lead to some subtle changes, all objects on the heap distribution also become less absolute. The Java heap is also a major area of garbage collector management, and is sometimes referred to as a GC heap. Amazingly, the Java heap can be in a physically discontinuous memory space, as long as it is logically contiguous. When the memory on the heap is exhausted and cannot be extended, OutOfMemoryError is thrown. Method Area
The method area, like the Java heap, is shared by all threads and is used to store data such as class information, constants, static variables, and Just-in-time compiler-compiled code that have been loaded by the virtual machine. The Java Virtual Machine specification has a very loose limit on the method area, and the Java heap does not require continuous physical space, can choose fixed size and scalability, and optionally does not implement garbage collection. It is necessary to implement garbage collection in this area, but it is more difficult to implement. OutOfMemoryError is thrown when the method area is unable to meet memory allocation requirements.