SpringBoot Jar启动

springBoot 专栏收录该内容
2 篇文章 0 订阅

SpringBoot项目的启动

当我们在IDE中新建(或导入)了一个SpringBoot项目之后,我们如果想要启动这个SpringBoot项目,我们可以找到相应的带有@SpringBootApplication注解的启动类,该启动类是一个带有main方法的类,这个类就是SpringBoot项目的入口。所以想要运行的话,只需要在IDE对这个类点击Run As Java Application既可以启动。

而当我们需要将写好的代码发布到相应的linux服务器上时。我们一般都是需要将我们的SpringBoot代码打成Jar包(即使是使用ops等自动化运维工具,其本质也是从git拉取到代码,然后mvn clean install打包代码进行发布),然后使用shell脚本执行jar包。我们打开所有的运行SPringBoot项目jar包的shell脚本,你都会发现在start的时候会执行:

java -jar  ****/SpringBoot.jar

实际上这句话最后的效果跟在IDE里对启动类点击Run As Java Application是一样,都是为了执行启动类中的main方法,从而完成SpringBoot初始化过程。
那么直接点击启动的方式当然好理解,但是你有想过为什么执行了java -jar命令后就能够执行启动类的main方法吗?
接下来,我们就先来探究这个问题。

SpringBoot jar的启动原理分析

  • 基础知识准备

0.java -jar命令到底做了什么

在jar包中,我们会在目录META-INF里发现一个叫做MANIFEST.MF的文件,在该文件中,有一个叫Main-Class的特殊条目。
而java -jar命令就是用来执行这个Main-Class指定的类。

  • 解析SpringBoot jar的结构

我们在对SpringBoot项目进行打包的时候,我们会执行Maven的mvn clean install命令,打完包后,你会在target目录上发现如下几个文件:

xxxx.jar
xxx.jar.original
xxx-sources.jar

最后一个文件很好理解,就是这个项目的源码jar。而第一个文件是在spring boot插件的机制下,将一个普通的jar打成了一个可以执行的jar包,而xxx.jar.original则是maven打出的jar包,

jar包结构

我们接着来看下xxx.jar这个spring boot插件作用下打出来的jar包的结构,解压后,结构如下:

.
├── BOOT-INF
│   ├── classes
│   │   ├── application-dev.properties
│   │   ├── application-prod.properties
│   │   ├── application.properties
│   │   ├── com
│   │   │   └── weibangong
│   │   │       └── open
│   │   │           └── openapi
│   │   │               ├── SpringBootWebApplication.class
│   │   │               ├── config
│   │   │               │   ├── ProxyServletConfiguration.class
│   │   │               │   └── SwaggerConfig.class
│   │   │               ├── oauth2
│   │   │               │   ├── controller
│   │   │               │   │   ├── AccessTokenController.class
│   │   ├── logback-spring.xml
│   │   └── static
│   │       ├── css
│   │       │   └── guru.css
│   │       ├── images
│   │       │   ├── FBcover1200x628.png
│   │       │   └── NewBannerBOOTS_2.png
│   └── lib
│       ├── accessors-smart-1.1.jar
├── META-INF
│   ├── MANIFEST.MF
│   └── maven
│       └── com.weibangong.open
│           └── open-server-openapi
│               ├── pom.properties
│               └── pom.xml
└── org
    └── springframework
        └── boot
            └── loader
                ├── ExecutableArchiveLauncher$1.class
                ├── ExecutableArchiveLauncher.class
                ├── JarLauncher.class
                ├── LaunchedURLClassLoader$1.class
                ├── LaunchedURLClassLoader.class
                ├── Launcher.class
                ├── archive
                │   ├── Archive$Entry.class
                │   ├── Archive$EntryFilter.class
                │   ├── Archive.class
                │   ├── ExplodedArchive$1.class
                │   ├── ExplodedArchive$FileEntry.class
                │   ├── ExplodedArchive$FileEntryIterator$EntryComparator.class
                    ├── ExplodedArchive$FileEntryIterator.class

这个jar除了我们写的应用程序打出的class以外还有一个单独的org包,应该是spring boot应用在打包的使用spring boot插件将这个package打进来,也就是增强了mvn生命周期中的package阶段,而正是这个包在启动过程中起到了关键的作用,另外把jar中将应用所需的各种依赖都打进来,并且打入了spring boot额外的package,这种可以all-in-one的jar也被称之为fat.jar,下文我们将一直以fat.jar来代替打出的jar的名字。

MANIFEST.MF文件
之前在提到java -jar命令的时候已经提到了这个文件了,那我们现在赶紧来看看Main-class是哪个,会是SpringBoot的启动类吗,如果直接就是SpringBoot启动类的话,那一切就解决了。

Manifest-Version: 1.0
Implementation-Title: iyourcar-service-game-carshow
Implementation-Version: 1.1.1
Archiver-Version: Plexus Archiver
Built-By: cc
Implementation-Vendor-Id: com.iyourcar
Spring-Boot-Version: 1.5.10.RELEASE
Implementation-Vendor: Pivotal Software, Inc.
Main-Class: org.springframework.boot.loader.PropertiesLauncher
Start-Class: com.iyourcar.App
Spring-Boot-Classes: BOOT-INF/classes/
Spring-Boot-Lib: BOOT-INF/lib/
Created-By: Apache Maven 3.3.9
Build-Jdk: 1.8.0_144
Implementation-URL: http://projects.spring.io/spring-boot/iyourcar-par
 ent-app/iyourcar-service-game-carshow/

我们可以看到Main-Class不是SpringBoot启动类,但是Start-Class是,那么我们就可以猜想,在执行Main-Class: org.springframework.boot.loader.PropertiesLauncher的main方法的过程中,会去执行Start-Class:com.iyourcar.App。这样就可以进行SpringBoot项目启动过程。
到底是不是这样呢,我们分析源码

  • 启动原理分析
    从上面的分析中,我们已经得到了java -jar命令执行的类是org.springframework.boot.loader.PropertiesLauncher

我们来看看这个类的main方法。

public static void main(String[] args) throws Exception {
        PropertiesLauncher launcher = new PropertiesLauncher();
        args = launcher.getArgs(args);
        launcher.launch(args);
}

launcher方法
这个方法在父类Launcher中,找到父类方法launch(String[] args)方法

 
  protected void launch(String[] args)
    throws Exception
  {
    JarFile.registerUrlProtocolHandler();
    //找到自定义类加载器
    ClassLoader classLoader = createClassLoader(getClassPathArchives());
    //
    launch(args, getMainClass(), classLoader);
  }
  

launch(args, getMainClass(), classLoader);

protected void launch(String[] args, String mainClass, ClassLoader classLoader)
    throws Exception
  {
  //设置当前线程的ClassLoader为SpringBoot插件中指定的自定义ClassLoader
    Thread.currentThread().setContextClassLoader(classLoader);
    createMainMethodRunner(mainClass, args, classLoader).run();
  }

我们查看源码可以发现,这个mainClass就是MANIFEST.MF文件中Start-Class的值。

getMainClass()
该方法是Launcher类中的一个抽象方法,实际实现在PropertiesLauncher类中。

 protected String getMainClass()
    throws Exception
  {
    String mainClass = getProperty("loader.main", "Start-Class");
    if (mainClass == null) {
      throw new IllegalStateException("No 'loader.main' or 'Start-Class' specified");
    }
    return mainClass;
  }
  
   private String getProperty(String propertyKey, String manifestKey)
    throws Exception
  {
    return getProperty(propertyKey, manifestKey, null);
  }
   private String getProperty(String propertyKey, String manifestKey, String defaultValue)
    throws Exception
  {
    if (manifestKey == null)
    {
      manifestKey = propertyKey.replace('.', '-');
      manifestKey = toCamelCase(manifestKey);
    }
    String property = SystemPropertyUtils.getProperty(propertyKey);
    if (property != null)
    {
      String value = SystemPropertyUtils.resolvePlaceholders(this.properties, property);
      
      debug("Property '" + propertyKey + "' from environment: " + value);
      return value;
    }
    if (this.properties.containsKey(propertyKey))
    {
      String value = SystemPropertyUtils.resolvePlaceholders(this.properties, this.properties
        .getProperty(propertyKey));
      debug("Property '" + propertyKey + "' from properties: " + value);
      return value;
    }
    try
    {
      if (this.home != null)
      {
        Manifest manifest = new ExplodedArchive(this.home, false).getManifest();
        if (manifest != null)
        {
          String value = manifest.getMainAttributes().getValue(manifestKey);
          if (value != null)
          {
            debug("Property '" + manifestKey + "' from home directory manifest: " + value);
            
            return SystemPropertyUtils.resolvePlaceholders(this.properties, value);
          }
        }
      }
    }
    catch (IllegalStateException localIllegalStateException) {}
    Manifest manifest = createArchive().getManifest();
    if (manifest != null)
    {
      String value = manifest.getMainAttributes().getValue(manifestKey);
      if (value != null)
      {
        debug("Property '" + manifestKey + "' from archive manifest: " + value);
        return SystemPropertyUtils.resolvePlaceholders(this.properties, value);
      }
    }
    return defaultValue == null ? defaultValue : 
      SystemPropertyUtils.resolvePlaceholders(this.properties, defaultValue);
  }
  
  

我们接着回到launch(args, getMainClass(), classLoader);方法,它最终调用了createMainMethodRunner方法,后者实例化了MainMethodRunner对象并运行了run方法,我们转到MainMethodRunner源码中。

public class MainMethodRunner {
    private final String mainClassName;
    private final String[] args;

    public MainMethodRunner(String mainClass, String[] args) {
        this.mainClassName = mainClass;
        this.args = args == null?null:(String[])args.clone();
    }

    public void run() throws Exception {
    //这里将之前存入到当前线程的自定义ClassLoader取出来去加载com.iyourcar.App这个类
        Class mainClass = Thread.currentThread().getContextClassLoader().loadClass(this.mainClassName);
        Method mainMethod = mainClass.getDeclaredMethod("main", new Class[]{String[].class});
        mainMethod.invoke((Object)null, new Object[]{this.args});
    }
}

我们查看run方法,很明显的看到执行了Start-Class:com.iyourcar.App的main方法,到这里,SpringBoot jar启动的过程其实就分析完了。

SrpingBoot jar启动过程中的自定义ClassLoader

在之前的分析中,我们已经知道了SpringBoot项目入口启动类是由SpringBoot插件中的自定义ClassLoader进行类加载的。

//找到自定义类加载器
ClassLoader classLoader = createClassLoader(getClassPathArchives());
这行代码作为入口分析

 protected ClassLoader createClassLoader(List<Archive> archives)
    throws Exception
  {
    //将archives的url都添加到自定义ClassLoader中,我们要知道archives中都包含哪些URL
    List<URL> urls = new ArrayList(archives.size());
    for (Archive archive : archives) {
      urls.add(archive.getUrl());
    }
    return createClassLoader((URL[])urls.toArray(new URL[urls.size()]));
  }
  
   protected ClassLoader createClassLoader(URL[] urls)
    throws Exception
  {
    return new LaunchedURLClassLoader(urls, getClass().getClassLoader());
  }

先找到parent Archive

  protected final Archive createArchive()
    throws Exception
  {
  
  //获取JAR包所在路径
    ProtectionDomain protectionDomain = getClass().getProtectionDomain();
    CodeSource codeSource = protectionDomain.getCodeSource();
    URI location = codeSource == null ? null : codeSource.getLocation().toURI();
    String path = location == null ? null : location.getSchemeSpecificPart();
    if (path == null) {
      throw new IllegalStateException("Unable to determine code source archive");
    }
    File root = new File(path);
    if (!root.exists()) {
      throw new IllegalStateException("Unable to determine code source archive from " + root);
    }
    return root.isDirectory() ? new ExplodedArchive(root) : new JarFileArchive(root);
  }
}

这段代码是通过得到JAR包(或者Java程序)所在路径,接着用路径来封装一个Archvie。最后,我们得到的是new ExplodedArchive(root);

 protected List<Archive> getClassPathArchives()
    throws Exception
  {
  //paths 当没有设置loader.path这个系统属性的时候,是一个空的List
    List<Archive> lib = new ArrayList();
    //paths是一个空的list
    for (String path : this.paths) {
      for (Archive archive : getClassPathArchives(path)) {
        if ((archive instanceof ExplodedArchive))
        {
          List<Archive> nested = new ArrayList(archive.getNestedArchives(new ArchiveEntryFilter(null)));
          nested.add(0, archive);
          lib.addAll(nested);
        }
        else
        {
          lib.add(archive);
        }
      }
    }
    //到这里都是一个空的lib,实际上就是addNestedEntries这个方法添加了URL
    addNestedEntries(lib);
    return lib;
  }
  private void addNestedEntries(List<Archive> lib)
  {
    try
    {
      lib.addAll(this.parent.getNestedArchives(new Archive.EntryFilter()
      {
        public boolean matches(Archive.Entry entry)
        {
          if (entry.isDirectory()) {
            return entry.getName().equals("BOOT-INF/classes/");
          }
          return entry.getName().startsWith("BOOT-INF/lib/");
        }
      }));
    }
    catch (IOException localIOException) {}
  }
 

上述代码其实就是程序帮我们找到需要使用自定义ClassLoader加载的URL。
当我们没有设置loader.path这个系统属性的时候,我们拿到的paths其实是空的。
这种情况下,实际上注入URL只有addNestedEntries方法,结合ExplodedArchive源码,可以分析得到,添加的URL,包括BOOT-INF/classes下的所有文件(真正有效的是classes下的class文件),以及BOOT-INF/lib下的所有jar文件。

SpringBoot jar启动过程中的自定义ClassLoader

  
  protected Class<?> loadClass(String name, boolean resolve)
    throws ClassNotFoundException
  {
    Handler.setUseFastConnectionExceptions(true);
    try
    {
      try
      {
        definePackageIfNecessary(name);
      }
      catch (IllegalArgumentException ex)
      {
        if (getPackage(name) == null) {
          throw new AssertionError("Package " + name + " has already been defined but it could not be found");
        }
      }
      return super.loadClass(name, resolve);
    }
    finally
    {
      Handler.setUseFastConnectionExceptions(false);
    }
  }
  
    private void definePackageIfNecessary(String className)
  {
    int lastDot = className.lastIndexOf('.');
    if (lastDot >= 0)
    {
      String packageName = className.substring(0, lastDot);
      if (getPackage(packageName) == null) {
        try
        {
          definePackage(className, packageName);
        }
        catch (IllegalArgumentException ex)
        {
          if (getPackage(packageName) == null) {
            throw new AssertionError("Package " + packageName + " has already been defined but it could not be found");
          }
        }
      }
    }
  }
    private void definePackage(final String className, final String packageName)
  {
    try
    {
      AccessController.doPrivileged(new PrivilegedExceptionAction()
      {
        public Object run()
          throws ClassNotFoundException
        {
          String packageEntryName = packageName.replace('.', '/') + "/";
          String classEntryName = className.replace('.', '/') + ".class";
          for (URL url : LaunchedURLClassLoader.this.getURLs()) {
            try
            {
              URLConnection connection = url.openConnection();
              if ((connection instanceof JarURLConnection))
              {
                java.util.jar.JarFile jarFile = ((JarURLConnection)connection).getJarFile();
                if ((jarFile.getEntry(classEntryName) != null) && 
                  (jarFile.getEntry(packageEntryName) != null) && 
                  (jarFile.getManifest() != null))
                {
                  LaunchedURLClassLoader.this.definePackage(packageName, jarFile.getManifest(), url);
                  
                  return null;
                }
              }
            }
            catch (IOException localIOException) {}
          }
          return null;
        }
      }, AccessController.getContext());
    }
    catch (PrivilegedActionException localPrivilegedActionException) {}
  }
  

这一部分其实就是springboot扩展URLClassLoader实现嵌套jar加载,这部分需要找个时间另写一篇文章来梳理,内容还是挺多的。

在看这部分的时候,我一直带着一个疑问,BOOT-INF/classes下面的文件都是class文件,应该是可以使用AppClassLoader(java 命令 加了-jar 参数以后,AppClassloader就只关注xxx.jar范围内的class了)这个类加载器直接加载的,那为什么需要使用自定义加载器来加载SpringBoot项目的启动入口类呢?
其实答案是很简单的,只是我当时钻牛角尖了。因为启动了这个入口类之后,我们后续是会这个入口类去加载Spring等BooT-INF/lib下面的jar包里的class的,而要加载这些类,我们是必须要用到这个自定义ClassLoader才可以对这种jar-in-jar格式里的class进行类加载的。所以也就导致了入口类是必须使用这个ClassLoader来进行类加载的,否则将无法加载程序中使用到的jar包里的类,肯定会导致报错。
如果类A中引用了类B,Java虚拟机将使用加载类A的类加载器来加载类B 。这些jar包是需要自定义加载器去处理的,就算没有使用jar-in-jar的结构,这些jar包也是需要使用自定义加载器去处理,因为这些jar包里的资源,AppClassLoader以及其祖先类加载器(ExtClassLoader ,BootStrapClassLoader )都是无法加载的(虽然说是祖先类加载器,但是并不是继承关系,只是通过parent属性注入关联了这个类加载树))。

另,在查看Jar包中的Manifest.MF文件的时候。我发现公司的两个项目的Mian-Class条目对应的值是不一样的。
project1

Main-Class: org.springframework.boot.loader.PropertiesLauncher

project2

Main-Class: org.springframework.boot.loader.JarLauncher

这就引起了我的疑问,为什么会不一样呢?
先给出导致这个结果的原因。

之所以我们打出的Jar包会和之前的Jar包的结构不一样,是因为打包的时候使用了springboot插件导致的。springboot插件增强了maven package(只对maven打包工具而言)。而这个springboot插件的设置其实就在pom文件中。
基本配置如下:

    <plugins>
            <plugin>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-maven-plugin</artifactId>
            </plugin>
        </plugins>

插件是可以在parent pom.xml中的<pluginManagement>节点进行统一配置的,我们公司也是如此。
而造成两个项目的Main-Class不一样的原因就是两个项目使用的parent pom文件的版本不一样。
project1中的parent pom.xml

	<plugins>
				<plugin>
					<groupId>org.springframework.boot</groupId>
					<artifactId>spring-boot-maven-plugin</artifactId>
					<executions>
						<execution>
							<goals>
								<goal>repackage</goal>
							</goals>
						</execution>
					</executions>
					<configuration>
						<mainClass>${start-class}</mainClass>
						<layout>ZIP</layout>
						<addResources>true</addResources>
						<executable>true</executable>
						<fork>true</fork>
					</configuration>
				</plugin>
			</plugins>

project2 的parent pom.xml

		<pluginManagement>
			<plugins>
				<plugin>
					<groupId>org.springframework.boot</groupId>
					<artifactId>spring-boot-maven-plugin</artifactId>
					<executions>
						<execution>
							<goals>
								<goal>repackage</goal>
							</goals>
						</execution>
					</executions>
				</plugin>
			</plugins>
		</pluginManagement>

你会发现,project1中配置了<layout>ZIP</layout>
正是因为这个配置,更改了Main-Class的值为org.springframework.boot.loader.PropertiesLauncher。

那到底PropertiesLauncher和JarLauncher有什么区别呢?为什么要有这两种不同的配置呢?
通过源码分析,我们会发现,PropertiesLauncher可以算是JarLauncher的一种扩展,是一种功能上的增强(这两个都用来启动springboot项目)。PropertiesLauncher允许通过配置loader.path使得jar包可以去加载外部的jar。而JarLauncher只能处理jar-in-jar这种模式。通常来说使用JarLauncher作为Main-Class被称为fat-jar,而PropertiesLauncher则可以将fat-jar变成thin-jar,之所以可以这样做,正是应为PropertiesLauncher使得jar包可以去加载外部的jar。

当Java虚拟机要加载第一个类的时候,加载过程:

(1). 首先当前线程的类加载器去加载线程中的第一个类(当前线程的类加载器:Thread类中有一个get/setContextClassLoader(ClassLoader cl);方法,可以获取/指定本线程中的类加载器)

(2). 如果类A中引用了类B,Java虚拟机将使用加载类A的类加载器来加载类B

(3). 还可以直接调用ClassLoader.loadClass(String className)方法来指定某个类加载器去加载某个类
每个类加载器加载类时,又先委托给其上级类加载器当所有祖宗类加载器没有加载到类,回到发起者类加载器,还加载不了,则会抛出ClassNotFoundException,不是再去找发起者类加载器的儿子,因为没有getChild()方法。

  • 0
    点赞
  • 0
    评论
  • 0
    收藏
  • 一键三连
    一键三连
  • 扫一扫,分享海报

相关推荐
©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值