一、Windows打包与运行
打包与运行
- SpringBoot工程可以基于java环境下独立运行jar文件启动服务
- SpringBoot工程执行mvn命令package进行打包
- 执行jar命令:java –jar 工程名.jar
对SpringBoot项目打包(执行Maven构建指令package)
mvn package
打包后会产生一个与工程名类似的jar文件,其名称是由模块名+版本号+.jar组成的。
运行项目(执行启动指令)
java –jar springboot.jar
执行程序打包指令后,程序正常运行,与在Idea下执行程序没有区别。
在使用向导创建SpringBoot工程时,pom.xml文件中会有如下配置,这一段配置千万不能删除,否则打包后无法正常执行程序。
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
</plugin>
</plugins>
</build>
spring-boot-maven-plugin插件用于将当前程序打包成一个可以独立运行的程序包
二、SpringBoot工程独立运行的机制
1. 打包方式
普通jar包(如:mysql驱动的jar…)运行的时候会出现不可执行的现象,而我们的SpringBoot项目为什么能执行呢?其实是因为打包方式不一样。
在SpringBoot工程的pom.xml中有下面这组配置,这组配置决定了打包出来的程序包是否可以执行。
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
</plugin>
</plugins>
</build>
2. 对比启用配置和不启用打出来的包的区别
我们分别开启这段配置
和注释掉这段配置
分别执行两次打包,然后观察两次打包后的程序包的差别,共有3处比较明显的特征
- 打包后文件的大小不同
- 打包后所包含的内容不同
- 打包程序中个别文件内容不同
开启配置的程序包体积比不带配置的大了几百倍,那这里面都有什么呢?能差这么多?打开两个jar包:
我们发现内容也完全不一样
,仅有一个目录是一样的
,叫做META-INF。打开容量大的程序包中的BOOT-INF目录下的classes目录
,我们发现其中的内容居然和容量小的程序包中的内容完全一样。
原来大的程序包中除了包含小的程序包中的内容,还有别的东西。都有什么呢?回到BOOT-INF目录下,打开lib目录,里面显示了很多个jar文件。
仔细翻阅不难发现,这些jar文件都是我们制作这个工程时导入的坐标对应的文件。大概可以想明白了,SpringBoot程序为了让自己打包生成的程序可以独立运行,不仅将项目中自己开发的内容进行了打包,还把当前工程运行需要使用的jar包全部打包进来了。为什么这样做呢?就是为了可以独立运行。不依赖程序包外部的任何资源可以独立运行当前程序。
再看看大程序包还有什么不同之处,在最外层目录包含一个org目录,进入此目录,目录名是org\springframework\boot\loader,在里面可以找到一个JarLauncher.class的文件,先记得这个文件。再看这套目录名
,明显是一个Spring的目录名
,为什么要把Spring框架的东西打包到这个程序包中呢?
回到两个程序包的最外层目录,查看名称相同的文件夹META-INF下都有一个叫做MANIFEST.MF的文件,但是大小不同,打开文件,比较内容区别
小容量文件的MANIFEST.MF
Manifest-Version: 1.0
Implementation-Title: springboot_08_ssmp
Implementation-Version: 0.0.1-SNAPSHOT
Build-Jdk-Spec: 1.8
Created-By: Maven Jar Plugin 3.2.0
大容量文件的MANIFEST.MF
Manifest-Version: 1.0
Spring-Boot-Classpath-Index: BOOT-INF/classpath.idx
Implementation-Title: springboot_08_ssmp
Implementation-Version: 0.0.1-SNAPSHOT
Spring-Boot-Layers-Index: BOOT-INF/layers.idx
Start-Class: com.itheima.SSMPApplication
Spring-Boot-Classes: BOOT-INF/classes/
Spring-Boot-Lib: BOOT-INF/lib/
Build-Jdk-Spec: 1.8
Spring-Boot-Version: 2.5.4
Created-By: Maven Jar Plugin 3.2.0
Main-Class: org.springframework.boot.loader.JarLauncher
大文件中明显比小文件中多了几行信息,其中最后一行信息是Main-Class: org.springframework.boot.loader.JarLauncher。这句话什么意思呢?如果使用java -jar执行此程序包,将执行Main-Class属性配置的类,这个类恰巧就是前面看到的那个文件。原来SpringBoot打包程序中出现Spring框架的东西是为这里服务的。而这个org.springframework.boot.loader.JarLauncher类内部要查找Start-Class属性中配置的类,并执行对应的类。这个属性在当前配置中也存在,对应的就是我们的引导类类名。
3. 总结
- SpringBoot程序添加配置后会打出一个特殊的包,包含Spring框架部分功能,原始工程内容,原始工程依赖的jar包
- 首先读取MANIFEST.MF文件中的Main-Class属性,用来标记执行java -jar命令后运行的类
- JarLauncher类执行时会找到Start-Class属性,也就是启动类类名
- 运行启动类时会运行当前工程的内容
- 运行当前工程时会使用依赖的jar包,从lib目录中查找
看来SpringBoot打出来了包为了能够独立运行,简直是煞费苦心,将所有需要使用的资源全部都添加到了这个包里。这就是为什么这个jar包能独立运行的原因。
再来看之前的报错信息:
由于打包时没有使用那段配置,结果打包后形成了一个普通的jar包,在MANIFEST.MF文件中也就没有了Main-Class对应的属性了,所以运行时提示找不到主清单属性,这就是报错的原因。
三、Linux运行SpringBoot项目
- 上传安装包
- 执行jar命令:java –jar 工程名.jar
- Boot程序打包依赖SpringBoot对应的Maven插件即可打包 出可执行的jar包
- 运行jar包使用jar命令进行
- Windows与Linux下执行Boot打包程序流程相同,
仅需确保运行环境有效即可
四、Windows解决端口占用
# 查询端口
netstat -ano
# 查询指定端口
netstat -ano |findstr "端口号"
# 根据进程PID查询进程名称
tasklist |findstr "进程PID号"
# 根据PID杀死任务
taskkill /F /PID "进程PID号"
# 根据进程名称杀死任务
taskkill -f -t -im "进程名称"
五、Linux解决端口占用
# 显示所有进程
ps -ef
# 显示tomcat进程详情。能够查询出pid
ps -ef | grep tomcat
# 根据pid强制杀死进程
kill -9 pid
# 查找进程号为'pid'的进程使用的端口号
netstat -anp | grep pid