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

In this issue, the editor will bring you about the startup principle of SpringBoot FatJar. The article is rich in content and analyzes and narrates it from a professional point of view. I hope you can get something after reading this article.

URLStreamHandler

URL is often used to describe resources in java. URL has a method for opening the link java.net.URL#openConnection (). Because URL is used to express a variety of resources, the specific action of opening a resource is done by a subclass of the java.net.URLStreamHandler class. Depending on the protocol, there will be different handler implementations. JDK has a considerable number of built-in handler implementations to deal with different protocols. Such as jar, file, http and so on. There is a static HashTable property inside the URL that holds the mapping between the discovered protocol and the handler instance.

There are three ways to obtain URLStreamHandler

Implement the URLStreamHandlerFactory interface, which is set by the method URL.setURLStreamHandlerFactory. This property is a static property and can only be set once.

Provide a subclass of URLStreamHandler directly as one of the input parameters to the constructor of URL. But there are fixed specification requirements in JVM:

The class name of the subclass must be Handler, and the package name of the last level must be the name of the protocol. For example, if you customize the protocol implementation of Http, the class name must be xx.http.Handler.

When JVM starts, you need to set the java.protocol.handler.pkgs system property. If there are multiple implementation classes, use | to separate them. Because when JVM tries to find Handler, it gets the package name prefix from this attribute and ends up using the package name prefix. The protocol name .Handler attempts to initialize the class using the Class.forName method, and if the initialization is successful, the implementation of the class is used as the protocol implementation.

Archive

SpringBoot defines an interface to describe resources, that is, org.springframework.boot.loader.archive.Archive. There are two implementations of this interface, org.springframework.boot.loader.archive.ExplodedArchive and org.springframework.boot.loader.archive.JarFileArchive. The former is used to find resources in the folder directory, and the latter is used to find resources in the jar package environment. In fatJar packaged with SpringBoot, the latter is used.

Packing

SpringBoot uses plug-ins

Org.springframework.boot spring-boot-maven-plugin com.tccdemo.Eureka

After packaging, the layout of the packaged file is as follows:

Programs under the BOOT-INF folder compile class and dependent jar packages

Under the org directory is the startup-related package for SpringBoot.

Let's look at the contents of the description file MANIFEST.MF.

Manifest-Version: 1.0Implementation-Title: eurekaImplementation-Version: 1.0-SNAPSHOTBuilt-By: AdministratorImplementation-Vendor-Id: com.tccdemoSpring-Boot-Version: 2.0.2.RELEASEMain-Class: org.springframework.boot.loader.JarLauncherStart-Class: com.tccdemo.EurekaSpring-Boot-Classes: BOOT-INF/classes/Spring-Boot-Lib: BOOT-INF/lib/Created-By: Apache Maven 3.6.1Build-Jdk: 1.8.0_201Implementation-URL: http://www.example.com

The most obvious thing is that the startup class of the program is not the startup class of our project, but the JarLauncher of SpringBoot. Let's take a closer look at the role of this class.

SpringBoot start

First of all, let's take a look at the startup method.

Public static void main (String [] args) throws Exception {new JarLauncher () .launch (args);}

JarLauncher inherits from org.springframework.boot.loader.ExecutableArchiveLauncher. The main function of the no-parameter construction method of this class is to construct the JarFileArchive object of the FatJar where the current main method is located. Let's take a look at the launch method. This method mainly does two things:

The JarFileArchive object is constructed by taking FatJar as file as the input parameter. Get all the resource targets, get their Url, take these URL as parameters, and build a URLClassLoader.

Load the business class pointed to by Start-Class in the MANIFEST.MF file with the ClassLoader built in the first step, and execute the static method main. And then start the whole program.

Through the static method org.springframework.boot.loader.JarLauncher#main, the whole program can be started smoothly. The key here is that the SpringBoot custom classLoader can recognize the resources in the FatJar, including: projects in the specified directory compile class, projects in the directive directory rely on jar. By default, the AppClassLoader used by JDK to load applications can only load class files from the root directory of jar, and the format jar in jar is not supported.

To achieve this goal, SpringBoot first customizes content reading in jar in jar, that is, url paths that support multiple! / delimiters. SpringBoot customizes the following two aspects:

A subclass org.springframework.boot.loader.jar.Handler of java.net.URLStreamHandler is implemented. The Handler supports the recognition of multiple! / delimiters and the correct opening of URLConnection. The Connection opened is a custom org.springframework.boot.loader.jar.JarURLConnection implementation of SpringBoot.

A subclass org.springframework.boot.loader.jar.JarURLConnection of java.net.JarURLConnection is implemented. The link supports multiple! / delimiters and implements its own method of getting InputStream in this case. In order to get the input stream correctly in org.springframework.boot.loader.jar.JarURLConnection, SpringBoot has customized a set of tool classes and methods to read ZipFile. This part is closely related to the specification of ZIP compression algorithm, so it doesn't go any further.

Once you can read multiple url of! /, things become very simple. The launch method of ExecutableArchiveLauncher mentioned above builds a JarFileArchive with the current FatJar and gets all of its internal resource URL through this object, which contains the project compiled class and dependent jar packages. When you build these URL, you pass in the SpringBoot custom Handler. Pass the acquired URL array as a parameter to the custom ClassLoaderorg.springframework.boot.loader.LaunchedURLClassLoader. The ClassLoader inherits from UrlClassLoader. UrlClassLoader loads class by relying on the Url array passed in by the initial parameter, and tries to load the Class file in the resource that Url points to. With a custom Handler, it becomes easy to try to get resources from Url.

At this point, the ClassLoader customized by SpringBoot can load the class file of the dependent package in FatJar.

Expansion

SpringBoot provides a good idea, but its internal implementation is very complex, especially its own implementation of a parser for ZipFIle. But in essence, the work behind this is to be able to read the class file resources of Jar inside FatJar. That is, as long as there is a way to read these resources, you can actually load Class files. It can be done by relying on the JarFile provided by JDK itself. After reading all the resources, it is not difficult to customize a project implementation where ClassLoader loads and reads binary data to define Class objects. Of course, SpringBoot's custom Zip parsing can avoid frequent file decompression during the class loading phase and perform better.

The above is what the startup principle of SpringBoot FatJar shared by the editor is. If you happen to have similar doubts, you might as well refer to the above analysis to understand. If you want to know more about it, you are welcome to 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.