Shulou(Shulou.com)05/31 Report--

This article mainly introduces the relevant knowledge of "what are the knowledge points of the Java virtual machine". The editor shows you the operation process through an actual case, and the operation method is simple, fast and practical. I hope this article "what are the knowledge points of the Java virtual machine" can help you solve the problem.

What is the Java virtual machine

When you talk about the Java virtual machine, you may mean:

1. Abstract Java virtual machine specification

2. A concrete Java virtual machine implementation

3. A running Java virtual machine instance

Second, the life cycle of Java virtual machine

A running Java virtual machine has a clear task: to execute Java programs. He doesn't run until the program starts and stops when the program ends. If you run three programs on the same machine, you will have three running Java virtual machines.

The Java virtual machine always starts with a main () method, which must be public, return void, and directly accept an array of strings. When the program is executed, you must specify the class name of the package change main () method to the Java virtual machine.

The Main () method is the starting point of the program, and the thread it is executed is initialized to the initial thread of the program. He starts all the other threads in the program. There are two types of threads in Java: daemon threads (daemon) and normal threads (non-daemon). The daemon thread is the thread used by the Java virtual machine itself. For example, the thread responsible for garbage collection is a daemon thread. Of course, you can also set your program as a daemon thread. The initial thread containing the Main () method is not a daemon thread.

As long as there are ordinary threads executing in the Java virtual machine, the Java virtual machine will not stop. If you have sufficient permissions, you can call the exit () method to terminate the program.

Third, the architecture of Java virtual machine.

A series of subsystems, memory areas, data types, and usage guidelines are defined in the specification of the Java virtual machine. These components constitute the internal structure of the Java virtual machine. They not only provide a clear internal structure for the implementation of the Java virtual machine, but also strictly define the external behavior of the Java virtual machine.

Each Java virtual machine consists of a class loader subsystem (class loader subsystem) that loads the types (classes and interfaces) in the program and gives them a unique name. Each Java virtual machine has an execution engine (execution engine) responsible for executing the instructions contained in the loaded class.

The execution of the program requires a certain amount of memory space, such as bytecode, other additional information of the loaded class, objects in the program, parameters of the method, return values, local variables, processed intermediate variables, and so on. The Java virtual machine stores all this information in the data areas. Although the data zone is included in the implementation of each Java virtual machine, the specification of the data zone in Java virtual machine specification is very abstract. Many of the structural details are left to the Java virtual machine implementers. The memory structure varies greatly from one Java virtual machine to another. Some implementations may take up a lot of memory, while others may consume only a small amount of memory; some implementations may be able to use virtual memory, while others may not. This relatively refined Java virtual machine memory specification enables Java virtual machines to be implemented on a wide range of platforms.

Part of the data area is shared by the whole program, while the other parts are controlled by separate threads. Each Java virtual machine contains a method area (method area) and a heap (heap) that are shared by the entire program. After the Java virtual machine loads and parses a class, it saves the parsed information from the class file in the method area. All objects created when the program is executed are saved in the heap.

When a thread is created, it is assigned its own PC register "pc register" (program counter) and Java stack (Java stack). When the thread does not use the local method, the next instruction executed by the thread is saved in the PC register. The Java stack holds the state of a thread when it calls a method, including local variables, parameters of the calling method, return values, and intermediate variables that are processed. The state when a local method is called is saved in the local method stack (native method stacks), possibly in registers or other non-platform independent memory.

The Java stack consists of stack blocks (stack frames (or frames)). The stack block contains the state of the Java method call. When a thread calls a method, the Java virtual machine pushes a new block into the Java stack, and when the method ends, the Java virtual machine pops up and discards the corresponding block.

The Java virtual machine does not use registers to store the intermediate results of the calculation, but uses the Java stack to store the intermediate results. This makes the instructions of the Java virtual machine more compact and it is easier to implement the Java virtual machine on a device without registers.

The downward growth in the Java stack in the figure, thread three in the PC register is grayed out because it is executing a local method and its next execution instruction is not saved in the PC register.

4. Data type (Data Types)

The data used in all Java virtual machines has certain data types, and the data types and operations are strictly defined in the Java virtual machine specification. The data types in Java are divided into raw data types (primitive types) and reference data types (reference type). The reference type depends on the actual object, but not the object itself. Primitive data types do not depend on anything; they are the data they represent.

The raw data types in all Java programming languages are the original data types of the Java virtual machine, except for boolean. When the compiler compiles the Java source code to its own code, it uses int or byte to represent Boolean. In the Java virtual machine, an integer 0 is used to represent a Boolean false, and a non-zero integer is used to represent a Boolean true. Boolean arrays are represented as byte arrays, although they may be stored as byte arrays or byte blocks (bit fields) in the heap.

Except for Boolean, the primitive types in other Java languages are data types in the Java virtual machine. In Java, data types are divided into plastic byte,short,int,long;char and floating-point float,double. Data types in the Java language have the same scope on any host.

There is also a primitive data type return value type (returnValue) that cannot be used in the Java language in the Java virtual machine. This type is used to implement "finally clauses" in Java programs, as described in "Finally Clauses" in Chapter 18.

Reference types may be created as: class type (class type), interface type (interface type), array type (array type). They all refer to objects that are created dynamically. When the reference type references null, it means that no objects are referenced.

The Java virtual machine specification defines only the scope represented by each data type, not the space occupied by each type at storage time. It is up to the implementer of the Java virtual machine to decide how they are stored. For more information about floating-point types, see Chapter 14, "Floating Point Arithmetic."

TypeRange

Byte8-bit signed two's complement integer (- 27 to 27-1, inclusive)

Short16-bit signed two's complement integer (- 215 to 215-1, inclusive)

Int32-bit signed two's complement integer (- 231 to 231-1, inclusive)

Long64-bit signed two's complement integer (- 263 to 263-1, inclusive)

Char16-bit unsigned Unicode character (0 to 216-1, inclusive)

Float32-bit IEEE 754 single-precision float

Double64-bit IEEE 754 double-precision float

ReturnValueaddress of an opcode within the same method

Referencereference to an object on the heap, or null

5. Byte length

The smallest data unit word (word) in a Java virtual machine whose size is defined by the implementer of the Java virtual machine. But one word must be large enough to accommodate byte,short,int, and the word char,float,returnValue,reference; must be large enough to accommodate long,double. So virtual machine implementers should at least provide words no smaller than 31bits words, but it is best to choose the most efficient word length on a particular platform.

At run time, the Java program cannot determine the word length of the machine being run. Word length does not affect the behavior of the program, it is just a way of expression in the Java virtual machine.

VI. Class loader subsystem

There are two types of classloaders in the Java virtual machine: primitive classloader (primordial class loader) and classloader object (class loader objects). The original classloader is part of the Java virtual machine implementation, and the classloader object is part of the running program. Classes loaded by different loaders are divided by different namespaces.

The classloader invokes other parts of many Java virtual machines and many classes in the java.lang package. For example, the class loading object is an instance of the java.lang.ClassLoader subclass, and the methods in the ClassLoader class can access the class loading mechanism in the virtual machine; each class loaded by the Java virtual machine is represented as an instance of the java.lang.Class class. Like other objects, the classloader object and the Class object are stored in the heap, and the loaded information is saved in the method area.

1. Load, connect, initialize (Loading, Linking and Initialization)

The class loading subsystem is not only responsible for locating and loading class files, it does a lot of other things according to the following strict steps: (for specific information, see "Class Lifecycle" in Chapter 7)

1), load: find and import binary information of the specified type (class and interface)

2), connect: validate, prepare and parse

① verification: ensure the correctness of the import type

② preparation: allocates memory for types and initializes them to default values

③ parsing: parsing character references into direct drinking

3) initialization: call the Java code to initialize the class variable to the appropriate value

2. Original class loader (The Primordial Class Loader)

Each Java virtual machine must implement a raw class loader that can load classes that follow the class file format and are trusted. However, the specification of the Java virtual machine does not define how the class is loaded, which is up to the Java virtual machine implementer to decide. For a type with a given type name, the original loader must find the file with the type name plus ".class" and load it into the virtual machine.

3. Class loader object

Although the classloader object is part of the Java program, three methods in the ClassLoader class can access the classloading subsystem in the Java virtual machine.

1), protected final Class defineClass (…) Using this method, you can enter and leave a byte array and define a new type.

2), protected Class findSystemClass (String name): loads the specified class, and returns directly if it has already been loaded.

3) the protected final void resolveClass (Class c): defineClass () method simply loads a class, which is responsible for subsequent dynamic connection and initialization.

For more information, see Chapter 8, "connection Model" (The Linking Model).

4. Namespace

When multiple class loaders load the same class, in order to ensure the uniqueness of their names, the identity of the class loader that loads the class needs to be added before the class name. For more information, see Chapter 8, "connection Model" (The Linking Model).

7. Method area (The Method Area)

In the Java virtual machine, the information about the loaded type is stored in the method area. The organization of the written information in memory is defined by the implementer of the virtual machine. For example, if the virtual machine works on a "little-endian" processor, he can save the information in the "little-endian" format, although they are saved in the "big-endian" format in Java class files. Designers can store data in the representation format that is most suitable for parallel machines to ensure that the program can be executed as quickly as possible. However, on a device with very little memory, the implementer of the virtual machine will not take up a lot of memory.

All threads in the program share a method area, so the method to access the method area information must be thread-safe. If you have two threads to load a class called Lava, only one thread can be allowed to load the class, and the other must wait.

When the program is running, the size of the method area is variable, and the program can be extended at run time. Some Java virtual machine implementations can also customize the initial size, minimum and maximum values of the method area through parameters.

The method area can also be garbage collected. Because the inner part of the program is dynamically loaded by the class loader, all classes may become unreferenced (unreferenced). When the class is in this state, it can be garbage collected. Classes that are not loaded include two states, one is actually unloaded, and the other is the "unreferenced" state. For more information, see the class life cycle (The Lifetime of a Class) in Chapter 7.

1. Type information (Type Information)

For each loaded type, the following information is saved in the method area in the Java virtual machine:

1), full name of the type (The fully qualified name of the type)

2), the full name of the parent type of the type (unless there is no parent type, or the Frey form java.lang.Object) (The fully qualified name of the type í s direct superclass)

3), whether the type is a class or an class or an interface (Whether or not the type is a class)

4), type modifiers (public,private,protected,static,final,volatile,transient, etc.) (The type í s modifiers)

5), list of full names of all parent interfaces (An ordered list of the fully qualified names of any direct superinterfaces)

The data structure saved by the full name of the type is defined by the virtual machine implementer. In addition, the Java virtual machine also holds the following information for each type:

1), constant pool of type (The constant pool for the type)

2), information of the type field (Field information)

3), information about the type method (Method information)

4), all static class variables (non-constant) information (All class (static) variables declared in the type, except constants)

5), a reference to the classloader (A reference to class ClassLoader)

6), a reference to the Class class (A reference to class Class)

1), constant pool of type (The constant pool for the type)

An ordered set of constants that all types are used in a constant pool, containing direct constants (literals) such as strings, integers, floating-point constants, and symbolic references to types, fields, and methods. Each constant saved in the constant pool has an index, just like a field in an array. Because the constant pool holds character references to types, fields, and methods used by all types in the constant pool, it is also the main object for dynamic connections. For more information, see Chapter 6, "The Java Class File."

2), information of the type field (Field information)

Field name, field type, field modifiers (public,private,protected,static,final,volatile,transient, etc.), the order in which the fields are defined in the class.

3), information about the type method (Method information)

Method name, return value type of method (or void), number of method parameters, type and their order, field modifiers (public,private,protected,static,final,volatile,transient, etc.), order in which methods are defined in the class

If it is not abstract and local, it also needs to be saved.

The bytecode of the method, the size of the method's Operand stack and the size of the local variable area (details in a moment), and the exception list (see Chapter 17, "Exceptions" for details. )

4), class (static) variable (Class Variables)

Class variables are shared by all instances of the class and can be accessed even if not through an instance of the class. These variables are bound to the class (not to the instance of the class), so they are part of the logical data of the class. You need to allocate memory for the class variable (non-final) before the Java virtual machine can use this class

Constants (final) are treated differently from such class variables (non-final). When each type uses a constant, it copies a copy to its own constant pool. Constants are also stored in the method area like class variables, except that they are stored in the constant pool. It is possible that class variables are shared by all instances, while constant pools are unique to each instance. The Non-final class variable is saved as part of the type data that defines it (data for the type that declares them), while the final constant is saved as part of using his type data (data for any type that uses them). See Chapter 6, "The Java Class FileThe Java Class File" for details.

5), reference to the classloader (A reference to class ClassLoader)

For each type loaded by the Java virtual machine, the virtual machine must save whether the type is loaded by the original class loader or class loader. Those types that are loaded by the class loader must hold a reference to the class loader. This information is used when the classloader is dynamically connected. When one class references another class, the virtual machine must save that the referenced type is loaded by the same class loader, which is the process of the virtual machine maintaining different naming spaces. See Chapter 8, "The Linking Model" for details.

6), reference to the Class class (A reference to class Class)

The Java virtual machine creates an instance of the java.lang.Class class for each loaded type. You can also use methods of the Class class:

Public static Class forName (String className) to find or load a class and get an instance of the corresponding Class class. Through this instance of the Class class, we can access the information in the Java virtual machine method area. For more information, please see the JavaDoc of Class class.

2. Method list (Method Tables)

In order to access all the data stored in the method area more effectively, the storage structure of the data must be carefully designed. In all the method areas, in addition to the original information above, there is also a data structure designed to speed up storage, such as method lists. For each loaded non-abstract class, the Java virtual machine generates a list of methods for them, which holds references to all instance methods that the class may call, incorrectly reporting methods called in the parent class. For details, see Chapter 8, "The Linking Model", heap.

When a Java program creates an instance or array of a class, it allocates memory for the new object in the heap. There is only one heap in the virtual machine, and all threads share it.

1. Garbage collection (Garbage Collection)

Garbage collection is the main way to release objects that are not referenced. It may also move objects to reduce the fragmentation of the heap. Garbage collection is not strictly defined in the specification of the Java virtual machine, but the implementation of a Java virtual machine must manage its own heap in some way. See Chapter 9, "Garbage Collection" for details.

2. Object storage structure (Object Representation)

The specification of the Java virtual machine does not define how objects are stored in the heap. Each object mainly stores the object variables defined in its class and parent class. For a reference to a given object, the virtual machine must quickly navigate to the object's data. In addition, a method of referencing method object data through an object, such as a reference to an object in the method area, must be provided, so the data saved by an object often contains a pointer of some form to the method area.

One possible heap design is to divide the heap into two parts: a reference pool and an object pool. A reference to an object is a local pointer to the reference pool. Each entry in the reference pool contains two parts: a pointer to the object data in the object pool and a pointer to the object class data in the method area. This design can facilitate the defragmentation of Java virtual machine heap. When the virtual machine moves an object in the object pool, only the pointer address in the corresponding reference pool needs to be modified. But each time you access the object's data, you need to process the pointer twice. The following figure illustrates the design of this heap. HeapOfFish Applet in Chapter 9, "garbage Collection," demonstrates this design.

Another heap design is that a reference to an object is an offset pointer to a pile of data and to the corresponding object. This design facilitates the access of objects, but the movement of objects becomes extremely complex. The following figure illustrates this design.

When a program tries to convert an object to another type, the virtual machine needs to determine whether the conversion is the object's type or its parent type. A similar thing is done when the program applies the instanceof statement. When a program calls a method of an object, the virtual machine needs to be dynamically bound, and he must determine which type of method to call. This also needs to make the above judgment.

No matter which design the virtual machine implementer uses, he may save a similar list of methods for each object. Because it can improve the speed of object method calls, it is very important to improve the performance of the virtual machine, but the specification of the virtual machine does not require the implementation of similar data structures. The following figure describes this structure. The figure shows all the data structures associated with an object reference, including:

1), a pointer to type data

2), a list of methods for an object. A method list is an array of pointers to all possible object methods. The method data consists of three parts: the size of the opcode stack and the local variable area of the method stack; the bytecode of the method; and the exception list.

Objects in each Java virtual machine must be associated with a lock (mutex) for synchronizing multithreading. Only one object can have a lock on that object at a time. When a lock owns the object, he can apply for the lock multiple times, but the lock must be released the number of times to actually release the object lock. Many objects are not locked throughout the lifecycle, so this information needs to be added only when needed. Many Java virtual machine implementations do not include "locked data" in the object's data, but only generate the corresponding data when needed. In addition to implementing object locking, each object is logically associated with an implementation of "wait set". Lock help threads process shared data independently without interfering with other threads. "wait set" helps group threads work together to achieve the same goal. "wait set" is often achieved through the wait () and notify () methods of the Object class.

Garbage collection also requires information about whether objects in the heap are associated. The Java virtual machine specification states that a finalizer method that runs an object is garbage collected once, but the finalizer method is allowed to re-reference the object, and when the object is not referenced again, there is no need to call the finalize method again. So the virtual machine also needs to save information about whether the finalize method has been run. For more information, see "garbage Collection" in Chapter 9.

3. Save the array (Array Representation)

In Java, an array is a full-fledged object that, like the object, is stored in the heap with a reference to an instance of the Class class. All arrays of the same dimension and type have the same Class, regardless of the length of the array. The name of the corresponding Class is represented as a dimension and type. For example, the Class of an integer data is "[I", the byte 3D array Class is "[[B", and the two-dimensional object data Class is "[[Ljava.lang.Object").

A multidimensional array is represented as an array of arrays, such as the following figure:

The array must hold the length of the array, the data of the array, and references to some object array type data in the heap. Referenced by an array, the virtual machine should be able to get the length of an array, access specific data through the index, and call methods defined by Object. Object is the direct parent of all data classes. For more information, see Chapter 6, "Class Files."

9. PC register (program counter) (The Program Counter)

A program counter is created when each thread starts execution. The program counter is only one word long (word), so it can hold a local pointer and returnValue. When the thread executes, the program counter stores the address of the executing instruction, which can make a local pointer or an offset pointer starting from the method bytecode. If the local method is executed, the value of the program counter is not defined.

10. Java stack (The Java Stack)

When a thread starts, the Java virtual machine creates a Java stack for him. The Java stack records the state of threads with some discrete frame classes. There are only two operations for the Java virtual machine heap Java stack: push-in and pop-up frames.

The method being executed in the thread is called the current method (current method), and the frame corresponding to the current method is called the current frame (current frame). The class that defines the current method is called the current class, and the constant pool of the current class is called the current constant pool (current constant pool.). When the thread executes, the Java virtual machine tracks the current class and the current constant pool. But when a thread manipulates the data saved in a frame, it only manipulates the data of the current frame.

When a thread calls a method, the virtual machine generates a new frame and pushes it into the thread's Java stack. This new frame becomes the current frame. When the method executes, it uses the current frame to save the method's parameters, local variables, intermediate structures, and other data. There are two ways to exit the method: normal exit and abnormal push. No matter which way the method is launched, the Java virtual machine pops up and discards the frame of the method, and the frame of the previous method becomes the current frame.

All data saved in the frame can only be accessed by the thread that owns it, and the thread cannot access the data in the stack of other threads. Therefore, multithreaded synchronization does not need to be considered when accessing the local variables of the method.

Like the method area and heap, the Java stack does not require contiguous memory space; it can be stored in a scattered memory space or heap. The specific data and length of the stack are defined by the implementer of the Java virtual machine. Some implementations may provide ways to execute the maximum and minimum values of the stack.

11. Stack frame (The Stack Frame)

The stack frame consists of three parts: local variables, Operand stack, and frame data. Both local variables and Operand stacks are word in size, and they are determined when they are compiled. The size of the frame data depends on different implementations. When a program calls a method, the virtual machine takes the size of the local variable and Operand stack from the class data, creates an appropriate size and frame, and then pushes it into the Java stack.

1. Local variable (Local Variables)

Local variables are organized into an array counted from zero in the Java stack frame, and instructions get the corresponding values from the local variables area by providing their index. Int,float,reference, returnValue take up one word, byte,short,char is converted to int and then stored, long and doubel take up two words.

The instruction gets the value of long,doubel by providing the first of the two-word indexes. For example, if the value of a long is stored on index 3, 4, the instruction can get the value of this long type through 3.

The local variables area contains the parameters and local variables of the method. The compiler puts the parameters of the method in front of the array in the order they declare. But the compiler can arrange local variables arbitrarily in an array of local variables, and even two local variables can share the same address, for example, when two local variables are in two regions that do not overlap, just like the loop variable iJournal j.

The implementer of the virtual machine can use any structure to describe the data in the local variable area, and the virtual machine specification does not define how to store long and doubel.

2. Operand stack (Operand Stack)

Like local variables, the Operand stack is organized into an array of words. But instead of being accessed through indexes like local variables, access is achieved through push and pops values. If an instruction push a value into the stack, then the next instruction can pop and use that value.

Unlike program counters, Operand stacks cannot be accessed directly by instructions. Instructions can access Operand stacks directly. The Java virtual machine is stack-based, not register-based, because its instructions get operands from the stack, not in the same register. Of course, instructions can also go to operands from other places, such as the opcode after the instruction, or a constant pool. But Java virtual machine instructions mainly get the operands they need from the Operand stack.

The Java virtual machine treats the Operand stack as a workspace, and many instructions push the result back to the Operand stack after processing the popvalue from the Operand stack. The execution process of an add instruction is shown in the following figure: first execute iload_0 and iload_1 instructions to add the two numbers that need to be added from the local method area, and push to the Operand stack; then execute the iadd instruction, now pop two values, add, and put the result pusp into the Operand stack; finally execute the istore_2 instruction, pop the result, and assign the value to the local method area.

3. Frame data (Frame Data)

In addition to processing local variables and Operand stacks, java stack frames include data needed to support constant pools, method return values, and exception distribution, which are stored in the frame data.

When the virtual machine encounters an instruction pointing to a constant pool reference, it accesses the required information through a pointer to the constant area in the frame data. As mentioned earlier, references in the constant area are all symbolic references at the beginning. Even when the virtual machine checks these references, they are character references. So the virtual machine needs to convert this reference at this point.

When a method returns normally, the virtual machine needs to rebuild the stack frame of the method that called the method. If the finished method has a return value, the virtual machine needs to push that value into which Operand stack of the calling method.

The frame data also contains a reference to the exception table that the virtual machine uses to handle exceptions. The exception table defines a bytecode protected by the catch statement. The individual in each exception table contains the scope of the bytecode to be protected and the location of the bytecode that needs to be executed when the exception is caught. When a method throws an exception, the Java virtual machine uses the exception table to determine how to handle the exception. If the virtual machine finds a matching catch, it gives control to the catch statement. If no matching catch is found, the method returns with an exception, and the process continues in the called method.

In addition to the above three uses, frame data may also contain some implementation-dependent data, such as debugging information.

XII. Local method stack

The local method zone depends on different implementations of the virtual machine. The implementer of the virtual machine can decide which mechanism to use to execute the local method.

Any native method interface (Native Method Interface) uses some form of native method stack.

XIII. Executive engine

The core of an java virtual machine implementation is the execution engine. In the Java virtual machine specification, the execution engine is described as a series of instructions. For each instruction, the specification describes what they should do, but does not say how to do it.

1. Instruction set

In the Java virtual machine, the byte stream of a method is a sequence of instructions. Each instruction consists of an one-byte opcode (Opcode) and a possible Operand (Operands). The opcode indicates what to do, and the Operand provides some additional information that may be needed to execute the opcode. An abstract execution engine executes one instruction at a time. This process occurs in each thread of execution.

Sometimes, the execution engine may encounter an instruction that needs to call a local method, in which case the execution engine attempts to call the local method, but when the local method returns, the execution engine continues to execute the next instruction in the byte stream. The local approach can also be seen as an extension of the instruction set in the Java virtual machine.

Deciding which instruction to execute next is also part of the job of the execution engine. The execution engine has three ways to get the next instruction. Most instructions execute instructions that meet with him; some instructions, such as goto or return, determine their next instruction when they execute; when an instruction throws an exception, the execution engine determines the next instruction to execute by matching catch statements.

Platform independence, network mobility and security influence the design of Java virtual machine instruction set. Platform independence is one of the main factors affecting instruction set design. The stack-based structure enables Java virtual machines to be implemented on more platforms. Smaller opcodes and compact structure enable bytecodes to make more efficient use of network bandwidth. One-time bytecode verification makes the bytecode more secure without affecting too much performance.

2. Executive technology

Many execution techniques can be used in the implementation of the Java virtual machine: interpreting execution, just-in-time compilation (just-in-time compiling), hot-spot compiling,native execution in silicon.

3. Thread

The Java virtual machine specification defines a threading model for implementation on more platforms. One of the goals of the Java threading model can take advantage of local threads. Using native threads, threads in Java programs can actually execute simultaneously on multiprocessor machines.

One of the costs of the Java threading model is thread priority, and a Java thread can run at a priority of 1-10. 1 is the lowest and 10 is the highest. If designers use local threads, they may map these 10 priorities to local priorities. The Java virtual machine specification only defines that higher-priority threads can have some cpu time, and low-priority threads can get some cpu time when all high-priority threads are blocked, but this does not guarantee that low-priority threads cannot get a certain amount of cpu time when high-priority threads are not blocked. Therefore, if you need to collaborate between different threads, you must use "synchronizatoin".

Synchronization means two parts: object lock (object locking) and thread wait and activate (thread wait and notify). Object locks help threads can be undisturbed by other threads. Thread waiting and activation allows different threads to collaborate.

In the specification of Java virtual machines, Java threads are described as variables, main memory, and working memory. Each instance of a Java virtual machine has a main memory, which contains all program variables: object, number combination class variables. Each thread has its own working memory, and it keeps copies of the variables he might use. Rules:

1), copy the value of the variable from the main memory to the working memory

2) write the values in the working memory to the main memory

If a variable is not synchronized, the thread may update the variables in main memory in any order. In order to ensure the correct execution of multithreaded programs, the synchronization mechanism must be used.

Local method Interface (Native Method Interface)

The implementation of the Java virtual machine does not have to implement the local method interface. Some implementations may not support local method interfaces at all. The local method interface of Sun is JNI (Java Native Interface).

15. Machines in reality (The Real Machine)

Mathematical method: simulation (Eternal Math: a Simulation)

This is the end of the content about "what are the knowledge points of the Java virtual machine". Thank you for your reading. If you want to know more about the industry, you can follow the industry information channel. The editor will update different knowledge points for you every day.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.