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

Today, I would like to share with you the relevant knowledge points of java files, which are detailed in content and clear in logic. I believe most people still know too much about this knowledge, so share this article for your reference. I hope you can get something after reading this article.

The Class file format uses a pseudo structure similar to the C language structure to store data, in which there are only two data types: "unsigned number" and "table".

Unsigned numbers belong to basic data types. U1, U2, U4 and U8 represent 1-byte, 2-byte, 4-byte and 8-byte unsigned numbers respectively. Unsigned numbers can be used to describe numbers, index references, quantitative values or string values according to UTF-8 coding.

A table is a compound data type made up of multiple unsigned numbers or other tables as data items. For ease of distinction, the naming of all tables habitually ends with "_ info". A table is used to describe data with a hierarchical compound structure, and the whole Class file can also be regarded as a table in essence.

The first four bytes of each Class file are called Magic Number, and its only purpose is to determine whether the file is an Class file that can be accepted by the virtual machine. Not only Class files, but also many file format standards have the habit of using magic numbers for identification. For example, image formats, such as GIF or JPEG, have magic numbers in the header.

The magic number of Class files is very "romantic", with a value of 0xCAFEBABE. )

The next four bytes of the magic number store the version number of the Class file: the fifth and sixth bytes are minor version numbers (MinorVersion), and the seventh and eighth bytes are major version numbers (Major Version). The version number of Java starts from 45, and each major version of JDK after JDK 1.1adds up the major version number (JDK 1.0 / 1.1uses the version number of 45.0 / 45.3). The high version of JDK is compatible with previous versions of Class files, but cannot run later versions of Class files.

Constant pool

The constant pool entry is immediately followed by the major and minor version numbers. The constant pool can be compared to the resource warehouse in the Class file. It is the data most associated with other projects in the Class file structure, and is usually one of the data items that take up the largest space in the Class file. In addition, it is also the first table type data item to appear in the Class file.

There are two main types of constants stored in the constant pool: literal quantities (Literal) and symbolic references (Symbolic References). Literals are close to the concepts of constants at the Java language level, such as text strings, constant values declared as final, and so on. On the other hand, symbolic reference belongs to the concept of compilation principle, which mainly includes the following types of constants:

Packages that are exported or opened by the module (Package)

Fully qualified name of the class and interface (Fully Qualified Name)

The name and descriptor of the field (Descriptor)

The name and descriptor of the method

Method handle and method type (Method Handle, Method Type, Invoke Dynamic)

Dynamic call points and dynamic constants (Dynamically-Computed Call Site, Dynamically-Computed Constant)

When Java code compiles Javac, it does not have the step of "connecting" as C and C++ do, but dynamically connects when the virtual machine loads the Class file (see Chapter 7 for details). In other words, the layout information of each method and field in memory is not saved in the Class file, and the symbolic references of these fields and methods cannot get the real memory entry address without being converted by the virtual machine at run time, and can not be directly used by the virtual machine. When the virtual machine loads the class, it will obtain the corresponding symbol reference from the constant pool, and then parse and translate it to the specific memory address when the class is created or run.

Each constant in the constant pool is a table. At first, there are 11 kinds of table structure data with different structures in the constant table. Later, in order to better support dynamic language calls, four additional dynamic language-related constants [1] are added. In order to support the Java modular system (Jigsaw), two constants CONSTANT_Module_info and CONSTANT_Package_info are added, so as of JDK13 There are 17 different types of constants in the constant scale.

Incidentally, because methods, fields, and so on in Class files need to refer to CONSTANT_Utf8_ info constants to describe names, the maximum length of CONSTANT_Utf8_ info constants is the maximum length of methods and field names in Java. The maximum length here is the maximum value of length, that is, the maximum value that can be expressed by type U2 is 65535. So if a variable or method name is defined in a Java program that exceeds the English characters of 64KB, even if the rules and all characters are legal, it will not compile.

Classfile / D:/BaiduYunDownload/geekbang-lessons/thinking-in-spring/validation/target/classes/org/geekbang/thinking/in/spring/validation/TestClass.class

Last modified 2020-6-25; size 439 bytes

MD5 checksum 18760ee8065f9fb68d4dab7bd7450c4c

Compiled from "TestClass.java"

Public class org.geekbang.thinking.in.spring.validation.TestClass

Minor version: 0

Major version: 52

Flags: ACC_PUBLIC, ACC_SUPER

Constant pool:

# 1 = Methodref # 4.018 / / java/lang/Object. "": () V

# 2 = Fieldref # 3.019 / / org/geekbang/thinking/in/spring/validation/TestClass.m:I

# 3 = Class # 20 / / org/geekbang/thinking/in/spring/validation/TestClass

# 4 = Class # 21 / / java/lang/Object

# 5 = Utf8 m

# 6 = Utf8 I

# 7 = Utf8

# 8 = Utf8 () V

# 9 = Utf8 Code

# 10 = Utf8 LineNumberTable

# 11 = Utf8 LocalVariableTable

# 12 = Utf8 this

# 13 = Utf8 Lorg/geekbang/thinking/in/spring/validation/TestClass

# 14 = Utf8 inc

# 15 = Utf8 () I

# 16 = Utf8 SourceFile

# 17 = Utf8 TestClass.java

# 18 = NameAndType # 7 8 / "": () V

# 19 = NameAndType # 5 rime 6 / / mvv I

# 20 = Utf8 org/geekbang/thinking/in/spring/validation/TestClass

# 21 = Utf8 java/lang/Object

{

Public org.geekbang.thinking.in.spring.validation.TestClass ()

Descriptor: () V

Flags: ACC_PUBLIC

Code:

Stack=1, locals=1, args_size=1

0: aload_0

1: invokespecial # 1 / / Method java/lang/Object. "() V

4: return

LineNumberTable:

Line 3: 0

LocalVariableTable:

Start Length Slot Name Signature

0 5 0 this Lorg/geekbang/thinking/in/spring/validation/TestClass

Public int inc ()

Descriptor: () I

Flags: ACC_PUBLIC

Code:

Stack=2, locals=1, args_size=1

0: aload_0

1: getfield # 2 / / Field m:I

4: iconst_1

5: iadd

6: ireturn

LineNumberTable:

Line 7: 0

LocalVariableTable:

Start Length Slot Name Signature

0 7 0 this Lorg/geekbang/thinking/in/spring/validation/TestClass

}

SourceFile: "TestClass.java"

At the end of the constant pool, the next two bytes represent the access flag (access_flags), which is used to identify access information at the class or interface level, including: whether the Class is a class or an interface; whether it is defined as a public type; whether it is defined as an abstract type; and if so, whether it is declared as final

The class index, the parent index, and the interface index collection are all arranged sequentially after the access flags. The class index and the parent index are represented by two index values of type U2, each pointing to a class descriptor constant of type CONSTANT_Class_info. The fully qualified name string defined in the constant of type CONSTANT_Utf8_info can be found through the index value in the constant of type CONSTANT_Utf8_info.

It was not until the emergence of Lambda expressions and interface default methods in JDK 8 that InvokeDynamic instructions had the opportunity to display their talents in the Class files generated by the Java language.

So this new property in JDK 8 allows the compiler to

(add the-parameters parameter when compiling) write the method name to the Class file, and MethodParameters is the attribute of the method table

Property, at the same level as the Code property, can be obtained at run time through reflection API.

Load a local variable into the operation stack: iload

Store a value from the Operand stack to the local variable table: istore

Load a constant into the Operand stack: bipush

Iload_, represents the instructions iload_0, iload_1, iload_2 and iload_3

Addition instructions: iadd, ladd, fadd, dadd

Subtraction instructions: isub, lsub, fsub, dsub

Multiplication instructions: imul, lmul, fmul, dmul

Division instructions: idiv, ldiv, fdiv, ddiv

Remainder instructions: irem, lrem, frem, drem

Reverse instruction: ineg, lneg, fneg, dneg

Displacement instructions: ishl, ishr, iushr, lshl, lshr, lushr

Bitwise or instruction: ior, lor

Bitwise and instruction: iand, land

Bitwise XOR instructions: ixor, lxor

Local variable self-increment instruction: iinc

Comparison instructions: dcmpg, dcmpl, fcmpg, fcmpl, lcmp

The semantics of the invokespecial instruction was changed in JDK 1.0.2, and JDK 7 added the invokedynamic instruction and banned the ret and jsr instructions.

The life cycle of a class

Load-> connect (verify, prepare, parse)-> initialize-> use-> uninstall.

The order of the five stages of loading, verification, preparation, initialization, and unloading is determined, and the loading process of the type must start step by step, while the parsing phase is not necessarily: it can start after the initialization phase in some cases to support the runtime binding features of the Java language (also known as dynamic or late binding).

Public static final int value = 123

At compile time, Javac will generate the ConstantValue attribute for value, and in the preparation phase, the virtual machine will assign value to 123 according to the settings of Con-stantValue.

The working process of the parent delegation model is that if a class loader receives a request for class loading, it will not attempt to load the class itself at first, but delegate the request to the parent class loader to complete it. This is the case with class loaders at every level, so all load requests should eventually be passed to the top-level startup class loader. Only when the parent loader reports that it cannot complete the load request (the required class is not found in its search scope), the child loader will try to complete the load on its own.

First, the extended classloader (Extension Class Loader) is replaced by the platform classloader (Platform Class Loader). This is actually a very logical change. Since the whole JDK is built based on modularization (the original rt.jar and tools.jar are split into dozens of JMOD files), the Java class library naturally meets the extensible needs, so there is no need to retain the\ lib\ ext directory. The previous mechanism of using this directory or java.ext.dirs system variables to extend JDK functions has no further value. The extended class loader used to load this part of the class library has also completed its historical mission.

All dispatching actions that rely on static types to determine the version of a method to perform are called static dispatches. The most typical application of static dispatch is method overloading. Static dispatch occurs during the compilation phase, so determining that the action of static dispatch is not actually performed by a virtual machine is why some data choose to classify it as "parsing" rather than "dispatching".

The following five method invocation bytecode instructions are supported in the Java virtual machine:

Invokestatic . Used to call static methods.

Invokespecial . Used to call instance constructor () methods, private methods, and methods in the parent class.

Invokevirtual . Used to call all virtual methods.

Invokeinterface . Used to call the interface method, another object that implements the interface is determined at run time.

Invokedynamic . The method referenced by the call point qualifier is dynamically parsed at run time before the method is executed. The first four call instructions and dispatch logic are fixed in the Java virtual machine, while the dispatch logic of invokedynamic instructions is determined by the boot method set by the user.

As long as the method can be called by invokestatic and invokespecial instructions, the unique calling version can be determined in the parsing phase. In Java language, there are four methods that meet this condition: static method, private method, instance constructor and parent method, plus the method modified by final (although it is called using invokevirtual instruction), these five method calls can quote symbols when the class is loaded.

Use to resolve to a direct reference to the method. These methods are collectively called "non-virtual methods" (Non-Virtual Method), whereas other methods are called "virtual methods" (Virtual Method).

Parsing calls must be a static process, and it is fully determined during compilation that all the symbolic references involved will be transformed into explicit direct references during the parsing phase of class loading, without having to delay completion until run time. Another main form of method call: Dispatch call is much more complex, it may be static or dynamic, according to the number of dispatches can be divided into single dispatch and multi-dispatch [1]. The pairwise combination of these two types of dispatch forms four kinds of dispatching combinations: static single dispatching, static multi-dispatching, dynamic single dispatching and dynamic multi-dispatching. Let's take a look at how the method dispatch in the virtual machine is carried out.

Two variables with the same static type but different actual types are deliberately defined in the code, but the virtual machine (or rather the compiler) is overloaded through the static type of the parameter rather than the actual type.

On the basis of judgment. Because the static type is known at compile time, the Javac compiler decides which overloaded version to use based on the static type of the parameter, so it chooses sayHello (Human) as the call target and writes the symbolic reference of this method to the parameters of the two invokevirtual instructions in the main () method.

All dispatching actions that rely on static types to determine the version of a method to perform are called static dispatches. The most typical application of static dispatch is method overloading. Static dispatch occurs during the compilation phase, so determining that the action of static dispatch is not actually performed by a virtual machine is why some data choose to classify it as "parsing" rather than "dispatching".

It can be seen that the overload priority of variable length parameters is the lowest. Fields never participate in polymorphism, and when a method of a class accesses a field with a name, the name refers to the field that the class can see.

Highlight

It is precisely because the first step in the execution of the invokevirtual instruction is to determine the actual type of the recipient at run time, so the invokevirtual instruction in the two calls does not end by parsing the symbolic reference of the method in the constant pool to the direct reference, but also selects the method version according to the actual type of the method receiver, which is the essence of method rewriting in the Java language. We refer to this process of dispatching a version of a method based on the actual type at run time as dynamic dispatch. The root of the polymorphism lies in the execution logic of the virtual method invocation instruction invokevirtual, so naturally our conclusion will only be valid for the method and invalid for the field, because the field does not use this instruction.

Java is a static multi-dispatching and dynamic single dispatching language.

For the convenience of program implementation, the method with the same signature should have the same index number in the virtual method table of the parent class and the subclass, so that when the type is changed, only the virtual method table needs to be changed. the desired entry address can be converted by index from different virtual method tables. The virtual method table is generally initialized in the connection phase of the class load. after the initial values of the variables of the class are prepared, the virtual machine initializes the virtual method table of the class.

Dynamically typed language support

The number of bytecode instruction sets of Java virtual machines since Sun's first Java virtual machine came out, only one instruction has been added in more than 20 years, which is the invokedynamic instruction, the first new member of bytecode issued with JDK 7. This new directive is one of the improvements made in JDK 7's project goal of dynamically typed language (Dynamically Typed Language) support, as well as a technical reserve for the smooth implementation of Lambda expressions in JDK 8.

What is a dynamically typed language [1]? The key feature of dynamically typed languages is that the main process of type checking takes place at run time rather than compile time. There are many languages that meet this feature, including APL, Clojure, Erlang, Groovy, javaScript, Lisp, Lua, PHP, Prolog, Python, Ruby, Smalltalk, Tcl, and so on. In contrast, languages that perform type checking at compile time, such as C++ and Java, are the most commonly used statically typed languages. Variables are untyped and variable values have types.

Providing direct support for dynamic types at the Java virtual machine level has become a problem that must be solved in the development of Java platform, which is the technical background of the invokedynamic directive and java.lang.invoke package in the JSR-292 proposal in JDK 7.

The new java.lang.invoke package [1] added in JDK 7 is an important part of JSR 292. the main purpose of this package is to provide a new mechanism for dynamically determining the target method, called "method handle", in addition to relying solely on symbolic references to determine the target method.

Both Reflection and MethodHandle mechanisms essentially simulate method calls, but Reflection simulates method calls at the Java code level, while MethodHandle simulates method calls at the bytecode level.

In the Tomcat directory structure, you can set up three sets of directories (/ common/*, / server/* and / shared/*, but not necessarily open by default, only the / lib/* directory exists) to store the Java class library, plus the Web application's own "/ WEB-INF/*" directory, a total of four groups. Place the Java class library in these four groups of directories, each with its own meaning, which are:

Put it in the / common directory. The class library can be used by Tomcat and all Web applications.

Put it in the / server directory. The class library is available to Tomcat and is not visible to all Web applications.

Put it in the / shared directory. The class library is common to all Web applications, but is not visible to Tomcat itself.

Put it in the / WebApp/WEB-INF directory. The class library can only be used by this Web application and is not visible to Tomcat and other Web applications.

In order to support this set of directory structure, and to load and isolate the class libraries in the directory, Tomcat customizes several class loaders, which are implemented according to the classical parent delegation model.

The Common classloader, Catalina classloader (also known as Server classloader), Sharedclassloader, and Webapp classloader are Tomcat-defined classloaders that load the Java class libraries in / common/*, / server/*, / shared/*, and / WebApp/WEB-INF/*, respectively. There are usually multiple instances of WebApp class loader and JSP class loader. Each Web application corresponds to a WebApp class loader and each JSP file corresponds to a WebApp class loader.

The loading scope of JasperLoader is only the Class file compiled by this JSP file, and its purpose is to be discarded: when the server detects that the JSP file has been modified, it will replace the current instance of JasperLoader and realize the HotSwap function of the JSP file by establishing a new JSP class loader.

These are all the contents of this article entitled "what are the knowledge points of java files?" Thank you for reading! I believe you will gain a lot after reading this article. The editor will update different knowledge for you every day. If you want to learn more knowledge, please pay attention to the industry information channel.

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.