“This is the fourth day of my participation in the Gwen Challenge in November. Check out the details: The Last Gwen Challenge in 2021.”

preface

Just learn Java when I know the Java virtual machine, all the Java code is running in the Java virtual machine, the advantage is a compilation and run many times, Java also because of such a mechanism to take a firm foothold, so how is the Java virtual machine? Look at the graph below

The JVM memory structure is made up of five parts: 1, the Method Area Method Area 2, 3, JVM Heap Heap stack 4 sports a virtual machine, PC Register the program counter 5, Native Method sports a local stack Method

So what exactly does it do? Keep reading

Methods area

The Method Area, like the Java heap, is an Area of memory shared by threads that stores data such as type information that has been loaded by the virtual machine, constants, static variables, and code caches compiled by the just-in-time compiler. Although the Java Virtual Machine Specification describes the method area as a logical part of the Heap, it has a nickname called “non-heap” to distinguish it from the Java Heap. – In-depth understanding of Java Virtual Machine version 3 2.2.5 methods area

  • An area shared by all virtual machine threads that stores member variables and method data
  • Method areas are created when the virtual machine is started, and may be implemented differently by different JVM vendors
  • It also runs out of heap memory (1.8 is out of meta memory, 1.6 is out of permanent memory, and 1.8 is not out of meta memory)

The heap

For Java applications, the Java Heap is the largest chunk of memory managed by the virtual machine. The Java heap is an area of memory that is shared by all threads and is created when the virtual machine is started. The sole purpose of this memory area is to hold object instances, and “almost” all object instances in the Java world are allocated memory here. Deep understanding of Java Virtual Machine version 3 2.2.4 Java heap

Common exceptions: Java heap memory overflow (OutOfMemoryError), where the contents of a variable are too large to be stored in stack memory. In plain English, you define variables in your Java program that exceed the size of the Java heap. Example:

The virtual machine stack

As each method is executed, the Java virtual machine synchronously creates a stack frame to store information about local variables, operand stacks, dynamic connections, method exits, and so on. The process of each method being called and executed corresponds to the process of a stack frame moving from the virtual machine stack to the virtual machine stack.

• Internal space required by threads to run (multiple stack frames for each stack frame: • Each stack consists of multiple stack frames, corresponding to the memory occupied by each method call. • Each thread can have only one active stack, corresponding to the method currently executing

• The larger the stack size, the smaller the number of threads will be (if the physical memory is 500 MB and the stack size is 1 MB per thread, then 500 threads can be allocated. If the stack size is 2 MB per thread, then only 250 threads can be allocated). So big stack memory is not recommended when the variable, or method is private, don’t need to worry about thread safety, when a variable or method for public or we have to consider when static thread-safe, because local variables are thread private, every method during different thread calls in the current stack memory to create a new variable, or method; However, if it is public or static, multiple threads will operate on a variable at the same time. Extension • Question: Are local variables within methods thread-safe?

A. A local variable within a method is thread-safe if it does not escape the action of the current method. B. If a local variable references a variable and escapes the function of a method, thread-safety concerns need to be addressed

• Question: Does garbage collection involve stack memory?

Garbage collection doesn’t involve stack memory, it doesn’t collect stuff that’s in stack memory, it just collects stuff that’s in heap memory.

Program counter

The bytecode interpreter works by changing the value of this counter to select the next bytecode instruction to be executed. It is an indicator of program control flow, and basic functions such as branch, loop, jump, exception handling and thread recovery depend on this counter.

What it does: • Remember the address of the next virtual machine instruction • Never runs out of memory, as the JAVA specification has established that this area does not run out of memory • Threads are private

Local method stack

The role of the Native method stack is very similar to that of the virtual machine stack, except that the virtual machine stack performs Java methods (that is, bytecode) services for the virtual machine, while the Native method stack serves the Native methods used by the virtual machine. Native modifications in JDK source code are usually made by calling implementations in other languages.

○ It is thread shared. All objects in the heap need to be considered thread safety. Garbage collection mechanism –