Java 项目打包优化：Jar 瘦身

Java 项目打包优化指南：Jar 瘦身与高效部署

方案	瘦身效果	稳定性	运维成本	适用场景
Docker 分层镜像	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐	容器化环境，追求极致的网络传输优化
依赖层/应用层分离	⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐	传统部署，需要清晰的分层结构
Thin Jar（官方思路）	⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐	Spring Boot 项目，希望保持原有启动方式

🎯 核心问题与解决思路

核心痛点：发布时网络传输消耗大，尤其是依赖未变更时重复传输相同内容。

核心理念 ：Jar 瘦身本身不是目的，减少重复传输才是关键。通过分层打包策略，将稳定不变的依赖层与频繁变动的业务层分离，可大幅降低每次发布的传输量。

✅ 方案一：Docker 镜像分层（推荐容器化方案）

原理说明

利用 Docker 镜像的分层机制：

基础层：操作系统 + JDK（几乎不变）
依赖层：第三方依赖库（变化较少）
应用层：业务代码（频繁变更）

每次发布时，Docker 引擎只会传输发生变更的层。当依赖未变化时，仅需传输业务代码层（通常仅几MB）。

预估效果

层次	体积范围	传输频率
基础层	80-150 MB	首次部署
依赖层	120-200 MB	依赖变更时
应用层	10-30 MB	每次发布（主要传输量）
每次发布平均传输量	≈ 10-30 MB

Dockerfile 示例（Spring Boot 项目）

dockerfile 复制代码

# 第一阶段：构建依赖层
FROM eclipse-temurin:8-jre as deps
WORKDIR /app
COPY target/lib/*.jar /app/lib/

# 第二阶段：构建最终镜像
FROM eclipse-temurin:8-jre
WORKDIR /app
COPY --from=deps /app/lib /app/lib
COPY target/app.jar /app/app.jar

ENTRYPOINT ["java", "-jar", "/app/app.jar"]

优势

✅ 传输效率极高：依赖不变时近乎零传输
✅ 镜像复用性好，节省存储空间
✅ 符合云原生最佳实践

注意事项

需具备 Docker 环境与相关运维能力
镜像仓库需要合理规划清理策略

✅ 方案二：依赖层与业务层分离（传统部署方案）

部署结构

复制代码

/deploy
 ├── lib/          # 第三方依赖（变更较少）
 │   ├── commons-io-2.11.0.jar
 │   ├── guava-31.1-jre.jar
 │   └── ...
 └── app.jar       # 业务代码（频繁变更）

启动方式

bash 复制代码

java -cp "app.jar:lib/*" com.ship.seacon.backend.SeaconShipBackendApplication

Maven 配置实现

xml 复制代码

<build>
    <plugins>
        <!-- 1. 标准编译配置 -->
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-compiler-plugin</artifactId>
            <version>3.8.1</version>
            <configuration>
                <source>1.8</source>
                <target>1.8</target>
                <encoding>UTF-8</encoding>
            </configuration>
        </plugin>

        <!-- 2. 生成仅包含业务代码的 app.jar -->
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-jar-plugin</artifactId>
            <version>3.3.0</version>
            <configuration>
                <finalName>app</finalName>
                <archive>
                    <manifest>
                        <addClasspath>true</addClasspath>
                        <classpathPrefix>lib/</classpathPrefix>
                        <mainClass>
                            com.ship.seacon.backend.SeaconShipBackendApplication
                        </mainClass>
                    </manifest>
                </archive>
            </configuration>
        </plugin>

        <!-- 3. 复制依赖到 lib/ 目录 -->
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-dependency-plugin</artifactId>
            <version>3.5.0</version>
            <executions>
                <execution>
                    <id>copy-dependencies</id>
                    <phase>package</phase>
                    <goals>
                        <goal>copy-dependencies</goal>
                    </goals>
                    <configuration>
                        <outputDirectory>${project.build.directory}/lib</outputDirectory>
                        <includeScope>runtime</includeScope>
                        <excludeTransitive>false</excludeTransitive>
                    </configuration>
                </execution>
            </executions>
        </plugin>

        <!-- 4. 禁用 Spring Boot 默认的 fat-jar 打包 -->
        <plugin>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-maven-plugin</artifactId>
            <version>${spring-boot.version}</version>
            <executions>
                <execution>
                    <id>repackage</id>
                    <phase>none</phase>  <!-- 禁用重新打包 -->
                </execution>
            </executions>
        </plugin>
    </plugins>
</build>

优势

✅ 部署结构清晰，运维人员易于理解
✅ 依赖与业务代码物理分离，传输量显著降低
✅ 无需容器化环境，适应传统部署场景

注意事项

需确保部署环境中 lib/ 目录与 app.jar 的相对路径正确
首次部署需完整传输所有文件

✅ 方案三：Spring Boot Thin Jar（官方轻量方案）

原理

Spring Boot 2.5+ 支持 Thin Jar 概念，通过外置依赖仓库减少 Jar 体积。应用启动时从指定位置（本地或远程）加载依赖。

实现方式

添加 Thin Launcher 依赖

xml 复制代码

<dependency>
    <groupId>org.springframework.boot.experimental</groupId>
    <artifactId>spring-boot-thin-launcher</artifactId>
    <version>1.0.28.RELEASE</version>
</dependency>

使用 Thin Jar 打包

xml 复制代码

<plugin>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-maven-plugin</artifactId>
    <configuration>
        <mainClass>${start-class}</mainClass>
    </configuration>
    <dependencies>
        <dependency>
            <groupId>org.springframework.boot.experimental</groupId>
            <artifactId>spring-boot-thin-launcher</artifactId>
            <version>1.0.28.RELEASE</version>
        </dependency>
    </dependencies>
</plugin>

优势

✅ 保持 Spring Boot 原生启动体验
✅ 可结合 Maven 仓库或本地缓存
✅ Jar 包体积显著减小

注意事项

首次启动需要下载依赖
需要稳定的网络或本地仓库环境

📊 方案选择建议

考虑因素	推荐方案	理由
已容器化，追求极致效率	Docker 分层镜像	利用分层机制，最大化复用，传输量最小
传统部署，结构清晰	依赖层/业务层分离	无需额外环境，运维直观，传输优化明显
Spring Boot 项目	Thin Jar	官方方案，兼容性好，保持标准启动方式

🚀 实施建议

评估现状：统计当前 Jar 包中依赖与业务代码的体积比例
试点验证：在非关键业务模块尝试一种方案，验证稳定性
完善流程：将打包优化集成到 CI/CD 流水线中
监控效果：记录部署时间与网络传输量变化，量化优化成果

通过合理的分层打包策略，可在保持应用稳定性的前提下，显著降低部署时的网络传输开销，提升发布效率。

提示：无论选择哪种方案，建议在实施前做好充分测试，并确保回滚机制可靠。