Shulou(Shulou.com)06/02 Report--

This article is to share with you about the life cycle of types in JVM. The editor thinks it is very practical, so I share it with you to learn. I hope you can get something after reading this article.

The following focuses on the life cycle of a type.

The life cycle of a type involves: class loading, jvm architecture, garbage collection mechanism.

Why talk about jvm architecture? Because the class loading and garbage collection mechanisms are closely related to the jvm architecture.

So what is the jvm architecture?

When jvm runs, it will request a memory area from the system (different jvm implementations may be different, some can use virtual memory), and divide this memory into parts to store many things, such as objects created by the program, parameters passed to the method, return values, local variables, etc., which we call the "runtime data area". The runtime data area can be divided into method area, heap, java stack, pc register and local method stack.

Looking at the picture above and these comments, you may have a rough idea of what the jvm system looks like, but you may not know what the method area in the runtime data area is for.

Method area: when the virtual machine loads a class file, it parses the type information from the binary data contained in the class file. However, these types of information are put into the method area. Because the method area is shared by all threads, thread safety of the data must be considered. If both threads are trying to find the lava class, only one thread should load while the other thread waits if the lava class has not been loaded.

Pc registers: each new thread generation will get its own pc register and a java stack frame.

Heap: stores all objects generated when the program is running. Heap is a thread-shared memory area, so we need to consider concurrency when writing multithreaded programs.

Java stack: the java stack consists of many stack frames, as shown in the figure. When a thread calls the java method, the virtual machine pushes a new stack frame into the java stack. When the method returns, the stack frame is popped up from the java stack and discarded.

So now you can imagine how some jvm works, should you go on to talk about how it works? But there is no hurry, first understand the loading mechanism of the following classes.

Before you understand the class loading mechanism, understand the class loaders in jvm: Bootstrap Loader, ExtClassLoader, AppClassLoader.

ExtClassLoader (responsible for loading rt.jar, charsets.jar under jre) and AppClassLoader (responsible for reprinting class packages under classpath) are subclasses of ClassLoader (abstract classes)

Bootstrap Loader (responsible for loading the jre core library) is the root loader that is written by cswab + and cannot be seen in java.

These three class loaders have a parent-child relationship. The root loader is the ExtClassLoader parent loader and ExtClassLoader is the AppClassLoader parent loader.

The loading of classes in Jvm is also the threshold of the security sandbox model. The Java load class uses the "parent delegation mode"-that is, overall responsibility for the delegation mechanism.

Okay, now let's get an idea of the loading process.

When loading a class, if the user specifies a class loader to load, then that class loader will first delegate to the parent class loader, all the way to the root loader. If you load a java.lang.String, because it belongs to the core class library and has already been loaded, it will directly return a class object. What if it is a class that the root loader cannot find? It is then handed over to the subclass (the next parent class) loader, and if the class file is still not found, it will then be loaded by the class loader specified by the previous user. The process of loading the superclass is not described here, please do not neglect it.

If someone maliciously wrote a basic class java.lang.String, will it affect the virtual machine? Not because this class will eventually be loaded by the root loader, but the root loader will only go to the jre core class library to load, the final returned class type is not user-written String, and the system comes with String, that is, user-written String will never be loaded.

Now that we understand how the classloader works, we also need to understand the class file format

The ClassFile Structure ClassFile {U4 magic; / / magic number U2 minor_version; / / class minor version number U2 major_version; / / class major version number U2 constant_pool_count; / / constant pool count cp_info constant_ pool [constant _ pool_count-1]; / / constant pool U2 access_flags; / / modifier U2 this_class; / constant pool index U2 interfaces_count; U2 interfaces [_ count]; U2 fields_count; field_info fields [fields _ count] U2 methods_count; method_info methods [methods _ count]; U2 attributes_count; attribute_info attributions [attractites _ count];}

There's a lot we need to know, but what we don't understand is the cp_info constant_pool constant pool.

There are many tables in a constant pool.

CONSTANT_Utf8 UTF-8 encoded Unicode string

Literal value of type CONSTANT_Integer int

Literal value of type CONSTANT_Float float

Literal value of type CONSTANT_Long long

Literal value of type CONSTANT_Double double

A symbolic reference to a class or interface by a CONSTANT_Class

References to literals of type CONSTANT_String String

CONSTANT_Fieldref 's symbolic reference to a field

CONSTANT_Methodref 's symbolic reference to a method in a class

CONSTANT_InterfaceMethodref 's symbolic reference to a method in an interface

A partial symbolic reference to a field or method by a CONSTANT_NameAndType

I'm not going to explain the structure of these tables.

It doesn't matter if you don't know enough about class files, it's probably OK to know one. So we understand the jvm system, classloader workflow, then we take a closer look at the classloader work, jvm runtime data area changes, the structure of the method area, and so on.

During class loading, each class loader forms a table in the method area that records the permission names of the loader and the corresponding class. Without such a table, it forms the namespace within jvm. At the same time, the constant pool and other information of this class is also returned in the method area.

Well, speaking of these, in fact, the process is still very vague, and a lot of knowledge has been left behind, so let's now look at a more detailed loading process.

When a normal class is loaded, the loadClass method of the class loader is called. If the class you want to load has not been loaded into the namespace, jvm passes a fully qualified name of that type to the classloader, that is, the loader of the entry of the constant pool CONSTANT_Class_info (the table stores information about the parent class, classloader, and so on) to attempt to load the referenced type. If the type that originates the reference is defined by the jvm loader, it is loaded by the jvm class loader, otherwise it is loaded by the user-defined loader, then once the referenced type is loaded, jvm carefully examines its binary data if the class is a class and is not java.lang.Object. Jvm loads (recursively applies) its fully qualified name based on the data. This process also requires recursive hyperinterfaces.

Loading is almost finished, a complete process is: load-connect-initialize

Then the connection and initialization go by, with an emphasis on garbage collection.

The process of connection is mainly verification (confirming that the type conforms to the semantics of the java language, and it does not endanger the integrity of the virtual machine), preparation (the java virtual machine allocates memory for class variables and designs default initial values), and parsing (the process of finding conformant references to classes, interfaces, fields, and methods in the constant pool of types and replacing these symbolic references with direct references).

During initialization, if there is a direct superclass in the class and the superclass has not been initialized, initialize the direct superclass first. Initializing an interface does not require initializing its parent interface.

Add:

Jvm when running a method, first push the method into the java stack, which contains local variables and other information, so where to put the object? What is pushed into the stack are references to objects, that is, variables, and all objects are stored in the heap.

Why put objects on the heap and data such as variables on the stack? To put it bluntly, the object is too large, so it is troublesome to store it in the stack. (of course, the standard answer is not like this. I'm just explaining the substance here.)

After understanding such a process, we must understand the garbage collection mechanism.

Basic recovery algorithm

Citation count: an older recycling algorithm. The principle is that this object has a reference, which increases a count, and deletes a reference reduces a count. For garbage collection, only objects with a count of 0 are collected. The deadliest thing about this algorithm is that it can't handle circular references.

Mark-clear: this algorithm is executed in two phases. The * * phase marks all referenced objects from the reference root node, and the second phase traverses the entire heap to clear the untagged objects. This algorithm needs to pause the entire application and generate memory fragmentation at the same time.

Copy: this algorithm divides the memory space into two equal regions, using only one area at a time. When garbage collection, traverse the current use area and copy the objects in use to another area. The secondary algorithm only deals with objects in use at a time, so the replication cost is relatively small, and the corresponding memory can be demarcated after copying, but there is a "fragmentation" problem. Of course, the disadvantage of this algorithm is also obvious, which requires twice the memory space.

Mark-organize: this algorithm combines the advantages of "mark-clear" and "copy" algorithms. It is also divided into two phases, the * phase marks all referenced objects from the root node, and the second phase traverses the entire heap, clearing the untagged objects and "compressing" the surviving objects into one of the pieces of the heap and discharging them sequentially. This algorithm not only avoids the fragmentation problem of "mark-clear", but also avoids the space problem of "copy" algorithm.

Incremental collection: implement the garbage collection algorithm, that is, garbage collection while the application is in progress.

Generation: a garbage collection algorithm based on the analysis of the life cycle of objects. The objects are divided into the young generation, the old generation and the persistent generation, and the objects with different life cycles are recycled using different algorithms (one of the above methods). Today's garbage collectors (starting with J2SE1.2) use this algorithm.

The above is what the life cycle of the type in JVM is, and the editor believes that there are some knowledge points that we may see or use in our daily work. I hope you can learn more from this article. For more details, please follow 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.