Wildfly中WAR内置JAR与jboss-deployment-structure.xml引用的差异及内存优势疑问

作为常年和WildFly打交道的开发者，我来给你拆解这两个问题：

这两种方式核心差异在于类加载机制、资源隔离性和维护方式，具体分这几点：

• 类加载范围与可见性
  内嵌在WAR的WEB-INF/lib目录下的JAR，由当前WAR专属的类加载器加载，类仅对当前WAR可见，完全隔离于其他部署；而通过jboss-deployment-structure.xml引用的JAR（通常是WildFly模块或者全局共享库），由模块级/共享类加载器加载，所有配置了相同依赖的部署都能访问这些类。

• 部署与更新灵活性
  内嵌JAR的WAR是独立的，要更新依赖库必须重新打包WAR并重新部署；而用XML引用的方式，只需要更新共享的JAR或模块，所有引用它的WAR会自动使用新版本，无需重新打包WAR，维护起来更高效。

• 类冲突风险
  内嵌JAR的模式下，不同WAR可以使用不同版本的同一款库，互相不会干扰，类冲突风险极低；但共享引用的模式下，所有WAR必须统一使用共享库的版本，一旦版本不兼容，很容易出现NoClassDefFoundError或IllegalAccessError这类类版本冲突问题。

• 部署包体积
  每个内嵌JAR的WAR都会包含一份依赖库的副本，如果多个WAR用相同库，总磁盘占用会重复；共享引用的话，库只需要存储一份，能大幅节省磁盘空间。

举个简单的jboss-deployment-structure.xml引用模块的例子：

<jboss-deployment-structure>
    <deployment>
        <dependencies>
            <!-- 引用自定义的共享模块 -->
            <module name="com.example.my-shared-lib" slot="main"/>
        </dependencies>
    </deployment>
</jboss-deployment-structure>

针对你提到的内存占用等收益，答案是肯定的，共享引用模式确实有明显优势：

• 显著降低内存占用
  这是最核心的收益。当多个WAR内嵌相同JAR时，每个WAR的类加载器都会把该JAR的类加载到JVM中——Java 8里是Metaspace区域（之前的PermGen），堆内存里也会存在重复的类对象实例，造成内存浪费；而共享引用模式下，类只会被共享类加载器加载一次，所有WAR共享这一份类数据，能大幅减少Metaspace和堆内存的占用，尤其当部署多个WAR且依赖库体积较大时，效果非常明显。

• 加快部署速度
  WildFly部署时需要解压、扫描并加载WAR中的所有JAR类文件。如果多个WAR都内嵌相同库，每个WAR都要重复处理这些库；而共享引用的话，库只需要被处理一次，整体部署速度会提升不少。

• 降低维护成本
  升级依赖库时，不需要逐个修改、重新打包所有WAR，只需要更新共享的模块或库即可，减少了重复劳动，也降低了人为出错的概率。

当然也要注意前提：所有WAR必须兼容共享库的版本，否则会出现类兼容性问题；另外要确保共享模块的权限配置正确，避免出现类访问权限不足的情况。

内容的提问来源于stack exchange，提问作者Dave