为什么SpringBoot胖Jar不再流行？
内容提要
JavaEE和Kubernetes试图解决构建可扩展分布式应用的复杂性，但失败了。现在，JavaEE可能会迎来复兴，Quarkus比Spring更现代。瘦jar比胖jar更好，可以提高开发效率和部署速度。
延伸解读
胖Jar在容器环境中的效率问题
文章指出，在容器化部署中，胖Jar将应用和所有依赖打包进单一Jar，导致镜像层无法有效复用。每次应用更新都需要重新构建和推送整个Jar，即使依赖未变。而瘦Jar将依赖与应用分离，利用Docker分层缓存，依赖层很少变动，只需推送应用层，显著减少推送时间和仓库空间。因此，胖Jar在容器环境中显得多余。
瘦Jar如何提升开发与部署效率
瘦Jar通过自定义类加载器加载依赖，启动速度比系统类加载器更快。在开发循环中，构建瘦Jar无需打包所有依赖，构建时间大幅缩短。部署时，将依赖和应用分别复制到不同镜像层，依赖层可复用，推送镜像时只需更新应用层。对于依赖众多的大型项目，推送时间可从几分钟缩短到几十秒，尤其适合网络条件不佳的场景。
应用服务器与容器化的资源管理对比
传统应用服务器在单个JVM中运行多个应用，一个应用内存泄漏可能导致整个JVM崩溃，影响所有应用。而容器化将每个应用隔离在独立容器中，一个应用崩溃不会波及其他应用，尽管内存效率可能较低，但可靠性更高。文章提到，早在容器出现前，就有公司通过自研调度器解决此问题，容器化进一步强化了这种隔离优势。
Quarkus与Spring Boot在打包方式上的差异
Quarkus默认生成瘦Jar（fast-jar），使用自定义类加载器加载依赖，启动更快。而Spring Boot默认生成胖Jar，虽可通过spring-boot-thin-launcher生成瘦Jar，但需额外配置。文章认为，在容器化世界中，分发的是容器而非Jar，因此胖Jar不再必要。Quarkus的瘦Jar方式更符合Java自然方式，且构建和部署效率更高。
Q&A
为什么Spring Boot的胖Jar在容器环境中不再流行？
在容器环境中，胖Jar将应用和所有依赖打包成一个单一Jar，导致镜像层无法有效复用，推送和拉取效率低。而瘦Jar将依赖与应用分离，可以利用Docker层缓存，依赖层很少变化，只需推送一次，大大节省网络传输和存储空间。此外，瘦Jar启动更快，因为Quarkus等框架使用自定义类加载器加载依赖。
瘦Jar相比胖Jar有哪些优势？
瘦Jar将应用代码与依赖库分离，依赖库放在单独的文件系统位置或镜像层中。优势包括：1) 构建时间缩短，无需打包巨大Jar；2) Docker镜像层可复用，依赖层很少变化，推送和拉取更快；3) 节省镜像仓库空间；4) 启动速度更快，如Quarkus使用自定义类加载器；5) 更符合Java自然方式，便于开发调试。
Quarkus为什么被认为比Spring更现代？
Quarkus基于JavaEE标准，默认生成瘦Jar（fast-jar），使用自定义类加载器加载依赖，速度比系统类加载器快很多。它更适应容器环境，启动快、内存占用少，并且支持GraalVM本地可执行文件。而Spring Boot已经过时，Micronaut、Quarkus和GraalVM才是未来趋势。
在容器中运行完整应用服务器有什么问题？
在容器中运行完整应用服务器没有意义：它很重、启动速度慢，而且失去了应用服务器的优势（如集中管理多个应用）。容器本身提供了可扩展性、声明式方法和自动重启等好处，无需应用服务器。此外，应用服务器的最大缺点是只能管理一个JVM，一个应用内存泄漏可能导致所有应用崩溃，而容器隔离性更好。
如何生成瘦Jar？有哪些工具或方法？
生成瘦Jar的方法包括：1) 使用Maven Jar插件配置MANIFEST.MF的Classpath条目，指定依赖路径；2) 使用spring-boot-thin-launcher生成精简Jar发行版；3) Quarkus默认生成fast-jar；4) 使用Jib创建多层容器，将依赖分层。关键是将依赖与应用分离，利用Docker层缓存。
JavaEE是否会复兴？它与Kubernetes有何相似之处？
JavaEE可能会复兴，因为其规范成功度过了Spring主导的时代，而基于JavaEE标准的Quarkus如今看起来比Spring更现代。JavaEE和Kubernetes都试图解决构建可扩展分布式应用的复杂性，但都未完全成功。两者都经历了从应用服务器集群到微服务、容器，再回到模块化单体的循环，应用服务器的集中管理思想在容器时代以新的形式重现。
