分类 其它 下的文章

用了这么多年的 SpringBoot 那么你知道什么是 SpringBootweb 类型推断吗?

估计很多小伙伴都不知道,毕竟平时开发做项目的时候做的都是普通的 web 项目并不需要什么特别的了解,不过抱着学习的心态,阿粉今天带大家看一下什么是 SpringBootweb 类型推断。

SpringBoot 的 web 类型有哪些

既然是web 类型推断,那我们肯定要知道 SpringBoot 支持哪些类型,然后才能分析是怎样进行类型推断的。

根据官方的介绍 SpringBootweb 类型有三种,分别是,NONESERVLETREACTIVE,定义在枚举 WebApplicationType 中,这三种类型分别代表了三种含义:

  1. NONE:不是一个 web 应用,不需要启动内置的 web 服务器;
  2. SERVLET:基于 servletweb 应用,需要启动一个内置的 servlet 服务器;
  3. REACTIVE:一个 reactiveweb 应用,需要启动一个内置的 reactive 服务器;
public enum WebApplicationType {
	NONE,
	SERVLET,
	REACTIVE;
}

web 类型推断

上面提到了 SpringBoot 的三种 web 类型,接下来我们先通过代码验证一下,然后再分析一下 SpringBoot 是如何进行类型推断的。

首先我们通过在 https://start.spring.io/ 快速的构建三种类型的项目,三种类型的项目配置除了依赖不一样之外,其他都一样,如下所示

None web

none

下载后的项目文件 pom 中对应的依赖为

<dependency>
			<groupId>org.springframework.boot</groupId>
			<artifactId>spring-boot-starter</artifactId>
</dependency>

Servlet web

servlet

下载后的项目文件 pom 中对应的依赖为

<dependency>
			<groupId>org.springframework.boot</groupId>
			<artifactId>spring-boot-starter-web</artifactId>
</dependency>

Reactive web

reactive

下载后的项目文件 pom 中对应的依赖为

<dependency>
			<groupId>org.springframework.boot</groupId>
			<artifactId>spring-boot-starter-webflux</artifactId>
</dependency>

接下来我们依次启动三个项目看看有什么区别,

启动 None web

none-web

通过启动日志我们可以看到,在 None web 类型下,应用启动运行后就自动关闭了,并没有启动内置的 web 服务器,也没有监听任何端口。接下来我们看看其他两种类型 web 的启动日志都是怎么样的。

启动 Servlet web

servelt-web

通过启动日志我们可以看到这里启动了内置的 Tomcat Servlet 服务器,监听了 8080 端口,应用程序并不会像 None 类型一样,启动后就自动关闭。

启动 Reactive web

reactive-web

通过启动日志我们可以看到,这里启动了内置的 Netty 服务器,并监听在 8080 端口上(如果启动失败记得把上面 servlet web 关闭,不然端口会冲突)。

三种类型的服务我们都成功启动了,那么接下来的问题就是 SpringBoot 是如何判断出该使用哪种类型的呢?

这三个服务我们只有依赖不一样,很明显肯定和依赖有关系,接下来我们就来研究一下 SpringBoot 是如何实现的。

SpringBoot Web 类型推断原理

我们在 main 方法中点击 run 方法,

public static ConfigurableApplicationContext run(Class<?>[] primarySources, String[] args) {
		return new SpringApplication(primarySources).run(args);
}

在构造函数中我们可以看到其中有这么一行 this.webApplicationType = WebApplicationType.deduceFromClasspath();根据属性名称我们可以推断,web 类型就是根据 WebApplicationType.deduceFromClasspath(); 这个静态方法来判断的。接下来我们看下这个方法的细节。

如上图所示,可以看到 SpringBoot 底层是通过 ClassUtils.isPresent() 方法来判断对应的 web 类型类是否存在来判断 web 类型的。

在前类路径下面如果当 org.springframework.web.reactive.DispatcherHandler 存在而且 org.springframework.web.servlet.DispatcherServletorg.glassfish.jersey.servlet.ServletContainer 都不存在的时候说明当前应用 web 类型为 Reactive

javax.servlet.Servletorg.springframework.web.context.ConfigurableWebApplicationContext 任何一个不存在的时候,就说明当前应用是 None 类型非 web 应用。否则当前应用就为 Servlet 类型。

而我们再看这个 ClassUtils.isPresent() 方法,可以发现底层是通过 className 在类路径上加载对应的类,如果存在则返回 true,如果不存在则返回 false
image-20221224154733977

因此这也解释了为什么我们在 pom 文件中只要加入对应的依赖就可以直接得到相应的 web 类型了,因为当我们在 pom 中加入相应的依赖过后,类路径里面就存在了前面判断的对应的类,再通过 ClassUtils.isPresent() 就判断出来当前应用属于那种 web 类型了。

内置服务器是如何创建的

知道了 SpringBoot 是如何进行 web 类型推断的,那么接下来一个问题就是 SpringBoot 是如何根据 web 类型进行相应内置 web 服务器的启动的呢?这里我们以 Reactive web 为例进行调试追踪。

首先我们在 SpringApplicationrun 方法 createApplicationContext() 下一行打断点,可以发现创建成功的 context 类型为 AnnotationConfigReactiveWebServerApplicationContext 很明显在这一步的时候就已经根据类型推断得到了当前的应用 web 类型为 Reactive,并且根据 web 类型创建出了对应的 ApplicationContext

reactive-web

紧接着我们进入 org.springframework.boot.SpringApplication#refreshContext 方法,最后我们可以进入到 org.springframework.boot.web.reactive.context.ReactiveWebServerApplicationContext#refresh 方法中,因为 AnnotationConfigReactiveWebServerApplicationContext 继承了 ReactiveWebServerApplicationContext

继续通过引用关系,我们可以找到 org.springframework.boot.web.reactive.context.ReactiveWebServerApplicationContext#onRefresh 方法,而在这个方法里面我们就会发现了如下代码,此处就会创建一个 webServer

具体创建的方法在 WebServerManager 里面,跟着继续往下找我们可以找到 createHttpServer() 方法,在 createHttpServer() 方法中就创建了 HttpServer 并且绑定了默认的端口 8080。具体过程,如下几张接入所示,感兴趣的可以自行跟踪 debug,至此一个 Reactive 内置服务器就创建成功了,同样的 Servlet 服务器也是类似的。




总结

Spring 的出现给 Java 程序员带来了春天,而 SpringBoot 框架的出现又极大的加速了程序员的开发效率,然而很多时候我们在使用她的便利的同时会缺少对于底层系统实现的把握,希望这篇文章弄帮助大家对 SpringBoot 产生更多的理解。

关于 SpringBoot 的自动装配功能,相信是每一个 Java 程序员天天都会用到的一个功能,但是它究竟是如何实现的呢?今天阿粉来带大家看一下。

自动装配案例

首先我们通过一个案例来看一下自动装配的效果,创建一个 SpringBoot 的项目,在 pom 文件中加入下面的依赖。

   <dependency>
	  <groupId>org.springframework.boot</groupId>
	  <artifactId>spring-boot-starter-web</artifactId>
    </dependency>

    <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-starter-data-redis</artifactId>
    </dependency>

其中 web 的依赖表示我们这是一个 web 项目,redis 的依赖就是我们这边是要验证的功能依赖。随后在 application.properties 配置文件中增加 redis 的相关配置如下

spring.redis.host=localhost
spring.redis.port=6379
spring.redis.password=123456

再编写一个 ControllerService 类,相关代码如下。

package com.example.demo.controller;

import com.example.demo.service.HelloService;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestParam;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class HelloController {

  @Autowired
  private HelloService helloService;
  
  @GetMapping(value = "/hello")
  public String hello(@RequestParam("name") String name) {
    return helloService.sayHello(name);
  }

}

service 代码如下

package com.example.demo.service;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.data.redis.core.RedisTemplate;
import org.springframework.stereotype.Service;

@Service
public class HelloService {

  @Autowired
  RedisTemplate<String, String> redisTemplate;

  public String sayHello(String name) {
    String result = doSomething(name);
    redisTemplate.opsForValue().set("name", result);
    result = redisTemplate.opsForValue().get("name");
    return "hello: " + result;
  }

  private String doSomething(String name) {
    return name + " 欢迎关注 Java 极客技术";
  }

}

启动项目,然后我们通过访问 http://127.0.0.1:8080/hello?name=ziyou,可以看到正常访问。接下来我们再通过 Redis 的客户端,去观察一下数据是否正确的写入到 Redis 中,效果跟我们想象的一致。

自动装配分析

看到这里很多小伙伴就会说,这个写法我天天都在使用,用起来是真的爽。虽然用起来是很爽,但是大家有没有想过一个问题,那就是在我们的 HelloService 中通过 @Autowired 注入了一个 RedisTemplate 类,但是我们的代码中并没有写过这个类,也没有使用类似于@RestController,@Service 这样的注解将 RedisTemplate 注入到 Spring IoC 容器中,那为什么我们就可以通过 @Autowired 注解从 IoC 容器中获取到 RedisTemplate 这个类呢?这里就是常说的自动装配的功能了。

首先我们看下项目的启动类,

package com.example.demo;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.EnableAutoConfiguration;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.context.annotation.ComponentScan;

@SpringBootApplication
@ComponentScan(value = "com.example.demo.*")
public class DemoApplication {

	public static void main(String[] args) {
		SpringApplication.run(DemoApplication.class, args);
	}
}

在启动类上面有一个 @SpringBootApplication 注解,我们点进去可以看到如下内容

@Target({ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Inherited
@SpringBootConfiguration
@EnableAutoConfiguration
@ComponentScan(
    excludeFilters = {@Filter(
    type = FilterType.CUSTOM,
    classes = {TypeExcludeFilter.class}
), @Filter(
    type = FilterType.CUSTOM,
    classes = {AutoConfigurationExcludeFilter.class}
)}
)
public @interface SpringBootApplication {
   // 省略
}

在这个注解中,其中有一个 @EnableAutoConfiguration 注解,正是因为有了这样一个注解,我们才得以实现自动装配的功能。继续往下面看。

@Target({ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Inherited
@AutoConfigurationPackage
@Import({AutoConfigurationImportSelector.class})
public @interface EnableAutoConfiguration {
    String ENABLED_OVERRIDE_PROPERTY = "spring.boot.enableautoconfiguration";

    Class<?>[] exclude() default {};

    String[] excludeName() default {};
}

可以看到 @EnableAutoConfiguration 注解中有一个 @Import({AutoConfigurationImportSelector.class}),导入了一个 AutoConfigurationImportSelector 类,该类间接实现了 ImportSelector 接口,实现了一个 String[] selectImports(AnnotationMetadata importingClassMetadata); 方法,这个方法的返回值是一个字符串数组,对应的是一系列主要注入到 Spring IoC 容器中的类名。当在 @Import 中导入一个 ImportSelector 的实现类之后,会把该实现类中返回的 Class 名称都装载到 IoC 容器中。

一旦被装载到 IoC 容器中过后,我们在后续就可以通过 @Autowired 来进行使用了。接下来我们看下 selectImports 方法里面的实现,当中引用了 getCandidateConfigurations 方法 ,其中的 ImportCandidates.load 方法我们可以看到是通过加载 String location = String.format("META-INF/spring/%s.imports", annotation.getName()); 对应路径下的 org.springframework.boot.autoconfigure.AutoConfiguration.imports 文件,其中就包含了很多自动装配的配置类。

protected List<String> getCandidateConfigurations(AnnotationMetadata metadata, AnnotationAttributes attributes) {
        List<String> configurations = new ArrayList(SpringFactoriesLoader.loadFactoryNames(this.getSpringFactoriesLoaderFactoryClass(), this.getBeanClassLoader()));
        ImportCandidates.load(AutoConfiguration.class, this.getBeanClassLoader()).forEach(configurations::add);
        Assert.notEmpty(configurations, "No auto configuration classes found in META-INF/spring.factories nor in META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports. If you are using a custom packaging, make sure that file is correct.");
        return configurations;
    }

我们可以看到这个文件中有一个 RedisAutoConfiguration 配置类,在这个配置中就有我们需要的 RedisTemplate 类的 Bean,同时也可以看到,在类上面有一个 @ConditionalOnClass({RedisOperations.class}) 注解,表示只要在类路径上有 RedisOperations.class 这个类的时候才会进行实例化。这也就是为什么只要我们添加了依赖,就可以自动装配的原因。

通过 org.springframework.boot.autoconfigure.AutoConfiguration.imports 这个文件,我们可以看到有很多官方帮我们实现好了配置类,这些功能只要我们在 pom 文件中添加对应的 starter 依赖,然后做一些简单的配置就可以直接使用。

其中本质上自动装配的原理很简单,本质上都需要实现一个配置类,只不过这个配置类是官方帮我们创建好了,再加了一些条件类注解,让对应的实例化只发生类类路径存在某些类的时候才会触发。这个配置类跟我们平常自己通过 JavaConfig 形式编写的配置类没有本质的区别。

自动装配总结

从上面的分析我们就可以看的出来,之所以很多时候我们使用 SpringBoot 是如此的简单,全都是依赖约定优于配置的思想,很多复杂的逻辑,在框架底层都帮我们做了默认的实现。虽然用起来很爽,但是很多时候会让程序员不懂原理,我们需要做的不仅是会使用,而更要知道底层的逻辑,才能走的更远。

基于上面的分析,我们还可以知道,如果我们要实现一个自己的 starter 其实也很简单,只要安装上面的约定,编写我们自己的配置类和配置文件即可。后面的文章阿粉会带你手写一个自己的 starter 来具体实现一下。


更多优质内容欢迎关注公众号【Java 极客技术】,我准备了一份面试资料,回复【bbbb07】免费领取。希望能在这寒冷的日子里,帮助到大家。

枯燥的编程中总得有些乐趣,今天我们不谈论那些高深的技能,教你几个在编程中的奇技淫巧,说不定在某些时候还能炫耀一番呢。

1、找到最大值和最小值

不使用 if else switch 和三元运算符,在给定的三元组中找到最大值和最小值:比如给定 3,14,8,在不使用 if else switch 和三元运算符的情况下找到最大值和最小值。

话不多说,我们先看代码

public static int findMax(int a, int b, int c) {
    int max = a;
    boolean b1 = (max < b) && ((max = b) > 0);
    b1 = (max < c) && ((max = c) > 0);
    return max;
  }

  public static int findMin(int a, int b, int c) {
    int min = a;
    boolean b1 = (min > b) && ((min = b) > 0);
    b1 = (min > c) && ((min = c) > 0);
    return min;
  }

这里我们主要使用了&& 运算符的短路特性,短路特性是指当 && 前一个表达式为 true 的时候才会继续执行下一个表达式,当前一个表达式为 false 则不会执行下一个表达式。所以在这里只有当前一个表达式为 true 的时候,后面的赋值语句才会被执行到。

我们运行一下结果如下

上面的这种方式入参适合正数和负数,如果当我们的入参能确定为正数的时候,我们还可以使用下面的这种方式来实现

  public static int findPositiveMax(int a, int b, int c) {
    int max = 0;
    while (a > 0 || b > 0 || c > 0) {
      a--;
      b--;
      c--;
      max++;
    }
    return max;
  }

  public static int findPositiveMin(int a, int b, int c) {
    int min = 0;
    while (a > 0 && b > 0 && c > 0) {
      a--;
      b--;
      c--;
      min++;
    }
    return min;
  }

上面的这种写法相信大家都能看懂,阿粉就不过的解释了,同样的这里也利用了&& || 运算的短路特性,不过要注意这种形式只能在都是正数的情况下才可以。

2、不使用临时变量交换变量

swap(x, y) 操作大家都知道,就是交互 x 和 y 的值,比如 x = 3, y = 4; 在经过 swap 操作过后,x = 4,y = 3;我们这里的问题时如何在不使用临时变量的情况下,只有一行代码来实现这个方法。

首先大家肯定知道这里我们要使用异或运算^,没错,话不多说我们看代码

public static void swapByXor(int x, int y) {
    System.out.println(x + ":" + y);
    x = x ^ y ^ (y = x);
    System.out.println(x + ":" + y);
  }

运行过后,可以看到,xy 的值已经被交换了, 这里我们要知道两个知识点,那就是 n ^ n = 0; n ^ 0 = n,另外a ^ bb ^ a 是等价的。

当然除了上面的异或之外,我们还可以通过下面这种方法来实现

public static void swapByAddAndSub(int x, int y) {
    System.out.println(x + ":" + y);
    x = x + y - (y = x);
    System.out.println(x + ":" + y);
  }

  public static void swapByMulAndDiv(int x, int y) {
    System.out.println(x + ":" + y);
    x = (x * y) / (y = x);
    System.out.println(x + ":" + y);
  }

这两种方式都是同样的逻辑,先求和在减去其中一个值和先求积再除以一个值,就可以得到两个替换后的值。

3、两个数相乘

接下来我们再看一个,求两个数的积,但是不能用乘号*。在看代码之前,我们先分析一下,比如说我们要求积 3 * 5 可以将 3 * 5 看成 3 * 4 + 3,也就是 (3 * 3 + 3) + 3,看到这个可能有的小伙伴已经知道我们要怎么计算了,没错,那就是我们可以用递归。

public static int mulWithoutMul(int x, int y) {
    if (y == 0)
      return 0;
    if (y > 0)
      return (x + mulWithoutMul(x, y - 1));
    return -mulWithoutMul(x, -y);
  }

通过上面的递归,我们就可以实现两个数相乘但是没有使用乘号了。

4、不使用乘号计算乘以 15

如果我们要计算一个数乘以 15 的时候,我们可以通过下面这种方式来计算,(n << 4) - n, 因 n * 15 = n * 16 - n = (n << 4) - n;同样的如果我们某些时候要计算乘以 2 或者除以 2 的时候,我们也可以换成移位操作,n * 2 = n << 1;n / 2 = n >> 1,如果是 4 的话就可以左移 2 位或者右移 2 位,即 n * 4 = n << 2;n / 4 = n >> 2;一次类推。

使用移位的方式,在某些极端的场景可以提升性能。

程序员必读书单


更多优质内容欢迎关注公众号【Java 极客技术】,我准备了一份面试资料,回复【bbbb07】免费领取。希望能在这寒冷的日子里,帮助到大家。

Java 程序员都知道要面向接口编程,那 Java 中的接口除了定义接口方法之外还能怎么用你知道吗?今天阿粉就来带大家看一下 Java 中的接口还可以有哪些用法。

基本特性

我们先看一下接口的基本特性

  1. 接口的定义需要使用关键字 interface
  2. 接口定义的所有方法默认都是 public abstract
  3. 当一个具体的 class 去实现一个interface时,需要使用implements 关键字;
  4. 接口之间是可以多继承,而类是只能单继承的;

如下所示,我们定义一个接口

package com.example.demo.inter;

import java.io.Serializable;
import java.util.RandomAccess;

/**
 * <br>
 * <b>Function:</b><br>
 * <b>Author:</b>@author java 极客技术<br>
 * <b>Date:</b>2022-09-24 17:38<br>
 * <b>Desc:</b>无<br>
 */
public interface ITest extends Serializable, RandomAccess {

  public abstract String sayHello();
  String sayHello2();// public abstract 可以省略

}

默认方法

JDK 8 之前接口是不支持默认方法的,在 JDK 8 之后接口支持默认方法,默认方法采用关键词 default 声明。

public interface ITest extends Serializable, RandomAccess {

  public abstract String sayHello();
  String sayHello2();// public abstract 省略
  
  // 默认方法
  default String sayHello3() {
    return "hello3";
  }

}

默认方法跟抽象方法不一样,接口中定义的抽象方法,当接口被其他类实现的时候都需要全部实现,但是默认方法是不需要被实现就可以直接使用的,类似于直接调用父类的方法一样,所以在很多时候,我们已经继承了一个类,还想有一个能用但是不想每个子类都实现的方法的时候,就可以考虑增加一个接口的默认方法来使用,简单来说就是实现类可以不覆写 default 方法。

default方法存在的目的是,在我们已经完善的项目中,如果我们直接给一个接口增加一个方法,在没有默认方法的时候就需要给所有的实现类都实现对应的方法,但是这个方法又不一定是每个实现类都需要的,所以这个时候默认方法就很好的解决了这个问题,我们只需要增加一个默认方法,然后在需要使用的实现类中进行实现或者使用就可以了,其他的实现类不需要改动任何的代码。

标记

接口还有一个很常见的功能那就是标记功能,这么说可能你没有印象,但是到提到序列化接口 java.io.Serializable; 你肯定知道,我们经常在对应的 POJO 中都会实现这个序列化接口,而这个序列化的接口如果看过源码的小伙伴肯定知道里面是没有内容的。

同样的功能除了序列化的接口,类似的空接口还有很多,比如 java.util.RandomAccess 也是空接口,之前阿粉也写过关于 RandomAccess 这个接口的用途,感兴趣的可以再去看看。 RandomAccess 明明是个空接口,能有什么用呢?

通过源码我们可以知道 RandomAccess 是用来标识子类是否实现了该接口,如果实现了则走实现了的逻辑,没有实现就走没有实现的逻辑,所以我们在日常开发中也可以利用这个特性,当我们有不同的子类需要根据情况进行不同的实现逻辑的时候就可以采用定义一个空接口来标记一下,方便后面的处理。

静态方法

跟默认方法一样,JDK 8 还支持在接口中增加静态方法,虽然说在接口中定义静态方法的做法不常见,但是当需要使用的时候也是可以支持的,避免在创建一个单独的工具类,跟在类中定义的静态方法一样,我们可以直接通过接口名称引用静态方法,当然静态变量也是可以的,使用方法一样。

public interface ITest extends Serializable, RandomAccess {

  public abstract String sayHello();
  String sayHello2();// public abstract 可以省略
  default String sayHello3() {
    System.out.println(sayHello4());
    return "hello3";
  }
  public static String sayHello4() {
    return "hello4";
  }
}

私有方法

大家有没有注意到,上面不管是默认方法还是静态方法其实都是 public 公开的,可以让实现类或者其他类直接使用,那有没有可能在接口中定义一个私有方法呢?在 JDK 9 之前是不可以的,JDK 9 却支持了,如下所示

  private void privateMethod() {
    System.out.println("private私有方法被调用");
  }

  private static void privateStaticMethod() {
    System.out.println("private私有静态方法被调用");
  }

从官方的文档中我们可以找到下面的描述,在 JDK 9 中接口支持私有方法,主要用于不同的非抽象方法中共享代码。

我们可以看到在 JDK 9 这样写是可以的

但是在 JDK8 就不行了,是无法编译通过的,会提示不允许使用 private 修饰符。

总结

今天阿粉给大家总结了一个接口的使用方法,后面在日常的开发中我们不单单只是在接口中定义抽象方法,也可以根据需求增加默认方法或者私有方法,以及在需要用到标记的时候也可以通过定义一个空接口来实现,怎么样是不是很棒,感觉动起来吧。最后觉得我们的文章有帮助,欢迎一键三连。


更多优质内容欢迎关注公众号【Java 极客技术】,我准备了一份面试资料,回复【bbbb07】免费领取。希望能在这寒冷的日子里,帮助到大家。

大家都知道我们常用的 SpringBoot 项目最终在线上运行的时候都是通过启动 java -jar xxx.jar 命令来运行的。

那你有没有想过一个问题,那就是当我们执行 java -jar 命令后,到底底层做了什么就启动了我们的 SpringBoot 应用呢?

或者说一个 SpringBoot 的应用到底是如何运行起来的呢?今天阿粉就带大家来看下。

认识 jar

在介绍 java -jar 运行原理之前我们先看一下 jar 包里面都包含了哪些内容,我们准备一个 SpringBoot 项目,通过在 https://start.spring.io/ 上我们可以快速创建一个 SpringBoot 项目,下载一个对应版本和报名的 zip 包。

下载后的项目我们在 pom 依赖里面可以看到有如下依赖,这个插件是我们构建可执行 jar 的前提,所以如果想要打包成一个 jar 那必须在 pom 有增加这个插件,从 start.spring.io 上创建的项目默认是会带上这个插件的。

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

接下来我们执行 mvn package,执行完过后在项目的 target 目录里面我们可以看到有如下两个 jar 包,我们分别把这两个 jar 解压一下看看里面的内容,.original 后缀的 jar 需要把后面的 .original 去掉就可以解压了。jar 文件的解压跟我们平常的 zip 解压是一样的,jar 文件采用的是 zip 压缩格式存储,所以任何可以解压 zip 文件的软件都可以解压 jar 文件。

解压过后,我们对比两种解压文件,可以发现,两个文件夹中的内容还是有很大区别的,如下所示,左侧是 demo-jar-0.0.1-SNAPSHOT.jar 右侧是对应的 original jar

其中有一些相同的文件夹和文件,比如 META-INFapplication.properties 等,而且我们可以明显的看到左侧的压缩包中有项目需要依赖的所有库文件,存放于 lib 文件夹中。

所以我们可以大胆的猜测,左侧的压缩包就是 spring-boot-maven-plugin 这个插件帮我们把依赖的库以及相应的文件调整了一下目录结构而生成的,事实其实也是如此。

java -jar 原理

首先我们要知道的是这个 java -jar 不是什么新的东西,而是 java 本身就自带的命令,而且 java -jar 命令在执行的时候,命令本身对于这个 jar 是不是 SpringBoot 项目是不感知的,只要是符合 Java 标准规范的 jar 都可以通过这个命令启动。

而在 Java 官方文档显示,当 -jar 参数存在的时候,jar 文件资源里面必须包含用 Main-Class 指定的一个启动类,而且同样根据规范这个资源文件 MANIFEST.MF 必须放在 /META-INF/ 目录下。对比我们上面解压后的文件,可以看到在左侧的资源文件 MANIFEST.MF 文件中有如图所示的一行。

![](/Users/silence/Library/Application Support/typora-user-images/image-20221206214011822.png)

可以看到这里的 Main-Class 属性配置的是 org.springframework.boot.loader.JarLauncher,而如果小伙伴更仔细一点的话,会发现我们项目的启动类也在这个文件里面,是通过 Start-Class 字段来表示的,Start-Class 这个属性不是 Java 官方的属性。

由此我们先大胆的猜测一下,当我们在执行 java -jar 的时候,由于我们的 jar 里面存在 MANIFEST.MF 文件,并且其中包含了 Main-Class 属性且配置了 org.springframework.boot.loader.JarLauncher 类,通过调用 JarLauncher 类结合 Start-Class 属性引导出我们项目的启动类进行启动。接下来我们就通过源码来验证一下这个猜想。

因为 JarLauncher 类是在 spring-boot-loader 模块,所以我们在 pom 文件中增加如下依赖,就可以下载源码进行跟踪了。

<dependency>
			<groupId>org.springframework.boot</groupId>
			<artifactId>spring-boot-loader</artifactId>
			<scope>provided</scope>
</dependency>

通过源码我们可以看到 JarLauncher 类的代码如下

package org.springframework.boot.loader;

import org.springframework.boot.loader.archive.Archive;
import org.springframework.boot.loader.archive.Archive.EntryFilter;

public class JarLauncher extends ExecutableArchiveLauncher {

	static final EntryFilter NESTED_ARCHIVE_ENTRY_FILTER = (entry) -> {
		if (entry.isDirectory()) {
			return entry.getName().equals("BOOT-INF/classes/");
		}
		return entry.getName().startsWith("BOOT-INF/lib/");
	};

	public JarLauncher() {
	}

	protected JarLauncher(Archive archive) {
		super(archive);
	}

	@Override
	protected boolean isPostProcessingClassPathArchives() {
		return false;
	}

	@Override
	protected boolean isNestedArchive(Archive.Entry entry) {
		return NESTED_ARCHIVE_ENTRY_FILTER.matches(entry);
	}

	@Override
	protected String getArchiveEntryPathPrefix() {
		return "BOOT-INF/";
	}

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

}

其中有两个点我们可以关注一下,第一个是这个类有一个 main 方法,这也是为什么 java -jar 命令可以进行引导的原因,毕竟 java 程序都是通过 main 方法进行运行的。其次是这里面有两个路径 BOOT-INF/classes/BOOT-INF/lib/ 这两个路径正好是我们的源码路径和第三方依赖路径。

JarLauncher 类里面的 main() 方法主要是运行 Launcher 里面的 launch() 方法,这几个类的关系图如下所示

跟着代码我们可以看到最终调用的是这个 run() 方法

而这里的参数 mainClasslaunchClass 都是通过通过下面的逻辑获取的,都是通过资源文件里面的 Start-Class 来进行获取的,这里正是我们项目的启动类,由此可以看到我们上面的猜想是正确的。

扩展

上面的类图当中我们还可以看到除了有 JarLauncher 以外还有一个 WarLauncher 类,确实我们的 SpringBoot 项目也是可以配置成 war 进行部署的。我们只需要将打包插件里面的 jar 更换成 war 即可。大家可以自行尝试重新打包解压进行分析,这里 war 包部署方式只研究学习就好了,SpringBoot 应用还是尽量都使用 Jar 的方式进行部署。

总结

通过上面的内容我们知道了当我们在执行 java -jar 的时候,根据 java 官方规范会引导 jar 包里面 MANIFEST.MF 文件中的 Main-Class 属性对应的启动类,该启动类中必须包含 main() 方法。

而对于我们 SpringBoot 项目构建的 jar 包,除了 Main-Class 属性外还会有一个 Start-Class 属性绑定的是我们项目的启动类,当我们在执行 java -jar 的时候优先引导的是 org.springframework.boot.loader.JarLauncher#main 方法,该方法内部会通过引导 Start-Class 属性来启动我们的应用代码。

通过上面的分析相比大家对于 SpringBoot 是如何通过 java -jar 进行启动了有了一个详细的了解,下次再有人问你 SpringBoot 项目是如何启动的,请把这篇文章转发给他。如果大家觉得我们的文章有帮助,欢迎点赞分享评论转发,一键三连。


更多优质内容欢迎关注公众号【Java 极客技术】,我准备了一份面试资料,回复【bbbb07】免费领取。希望能在这寒冷的日子里,帮助到大家。