In-depth understanding of java virtual machine knowledge points

1: Understanding of java virtual machine

The Java Virtual Machine is a virtual machine process that can execute Java bytecode . Java source files are compiled into bytecode files that can be executed by the Java virtual machine.

The cross-platform of java is not the cross-platform of the java source program. If so, then all languages ​​are cross-platform. The java source program is first compiled into a binary .class bytecode file by the javac compiler (the cross-platform of java refers to It is the cross-platform of the .class bytecode file, the .class bytecode file is independent of the platform), the .class file is then run on the jvm , and the java interpreter ( part of the jvm ) will interpret it as the machine of the corresponding platform Code execution, so the so -called cross-platform of java means that different jvms are installed on different platforms, and the .class files generated on different platforms are the same, and the .class files are then interpreted by the jvm of the corresponding platform into the corresponding platform. Machine code execution.

Finally, explain the difference between machine code and bytecode : 1. Machine code, which exists completely dependent on hardware ~ and different hardware has different embedded instruction sets, even the same 0 1 code may mean different ~ In other words, There is no cross-platform at all ~ for example ~ different models of CPU, you give him a command 10001101 , they may resolve to different results ~ Second, we know that JAVA is cross-platform, why? Because he has a jvm, no matter what kind of hardware, as long as you have a jvm installed, then he will know the JAVA bytecode~~~ As for the underlying machine code, we don't care, if the jvm is done, he will put the bytecode Then translate it into the machine code recognized by the machine where you are located~~~

 

The java virtual machine is a virtual machine process that can execute java bytecode

A virtual machine is an abstract computer that is implemented by simulating various computer functions on an actual computer. The Java virtual machine has its own complete hardware architecture, such as processor , stack , registers , etc., and also has a corresponding instruction system. The JVM shields the information related to the specific operating system platform, so that the Java program only needs to generate the object code ( bytecode ) running on the Java virtual machine , and it can run on various platforms without modification.

Let's try to understand virtual machines from an operating system level. We know that virtual machines run in the operating system, so what can run in the operating system? Of course it's a process, because a process is a unit of execution in an operating system. It can be understood in this way that when it is running, it is a process instance in the operating system, and when it is not running (stored in the file system as an executable file), it can be called a program.

Finally make a summary:

1 A  virtual machine is not mysterious, it is just an ordinary process from the point of view of the operating system.

This process called the virtual machine is special, it can load the class file we wrote. If the JVM is compared to a person, then the class file is the food we eat.

Loading class files is a subsystem called a class loader. Just like our mouths, we eat food into our stomachs.

The execution engine in the virtual machine is used to execute the bytecode instructions in the class file. Just like our stomach, it digests the food we eat.

During the execution of the virtual machine, it is necessary to allocate memory to create objects. When these objects become obsolete and useless, these useless objects must be cleaned up automatically. The task of cleaning up objects to reclaim memory is the responsibility of the garbage collector. Just like the food that people eat, after being digested, the waste must be excreted out of the body, making room for eating and digesting the food the next time you are hungry.

2: How does the jvm determine whether the object can be recycled

The content is basically from the third chapter of Zhou Zhiming's in-depth understanding of the second edition of the java virtual machine. This book is okay, but it seems that there are no other good books about jvm in Chinese.

When jvm does garbage collection, it must first determine whether an object is still likely to be used. So how do you judge whether an object is still likely to be used?

If our program can no longer refer to the object, then the object can definitely be recycled, this state is called unreachable. When an object is unreachable, the object can be reclaimed by the garbage collector as a reclaimed object.

So how to judge whether this is reachable or unreachable?

The answer is GC roots, that is, the root object. If there is no path from an object to the root object, or the object cannot be referenced from the root object, the object is unreachable.

The following three types of objects are used as GC roots in the jvm to determine whether an object can be recycled  (usually we only need to know the virtual machine stack and static references)

· 

The object referenced in the virtual machine stack (JVM stack) (to be precise, the stack frame (frames) in the virtual machine stack)  We know that when each method is executed, the jvm will create a corresponding stack frame (the stack frame includes Operand stack, local variable table, reference to runtime constant pool), the stack frame contains references to all objects used inside the method (of course other basic type data), when the method is executed, the stack frame It will be popped from the virtual machine stack, so that the reference to the temporarily created object does not exist, or there are no gc roots pointing to these temporary objects, and these objects will be recycled in the next GC.

· 

· 

The object  static property referenced by the class static property in the method area is the property of the type (class) and does not belong to any instance alone, so this property will naturally be used as gc roots. As long as the class exists, the object pointed to by the reference will also exist. class will also be recycled, which will be explained later

· 

· 

Objects referenced by the Native Stack

· 

For a class to be recycled, it should be unloaded, it must meet the following three conditions at the same time

no instance of the class exists in the heap 

The  classloader that loaded the class has been recycled

The java.lang.Class object of  the class is not referenced anywhere, that is to say, the information of the class cannot be accessed through reflection

 

This content is too little, I am talking about the four reference types in java

In fact, the difference between these four types of references is whether the object is reclaimed during GC

Strong  reference (Strong) is the way we usually use A a = new A(); strongly referenced objects will not be recycled

Soft reference (Soft) When the JVM wants out of  memory (OOM), it will recycle the soft reference object and release more memory

Weak reference (Weak) In the next GC ,  the weakly referenced object will definitely be recycled

The  virtual reference (Phantom) has no effect on the existence time of the object, nor can it refer to the strength of the object. The only effect is to receive a system notification when the object is recycled

 

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=325680730&siteId=291194637