JPMS不直接压缩堆内存，但通过精准控制类加载与卸载、精简模块依赖、构建轻量运行时及收紧元空间参数，显著降低元空间占用与启动内存。
Java 模块化系统（JPMS）本身不直接压缩堆内存，但它能从类加载源头控制元空间（Metaspace）膨胀、提升类卸载成功率、减少冗余类加载，从而显著降低核心运行时的内存占用。关键在于“让该加载的精准加载，让该释放的彻底释放”。
精简模块依赖，杜绝隐式加载
大量无用类被加载进元空间，是运行时内存占用居高不下的主因之一。模块化强制显式声明依赖，可有效拦截失控加载：
- 每个模块的 module-info.java 中只 requires 真正需要的 JDK 模块（如
java.base、java.sql）和第三方模块，禁用requires transitive除非明确需透传依赖 - 移除未使用的自动模块（Automatic-Module）：JAR 包若无
module-info.class，会被 JVM 转为松散命名的自动模块，易引发重复加载或类加载器泄漏；统一补全module-info.java或替换为真正模块化版本 - 禁用 Spring Boot 默认的组件扫描（
@ComponentScan）或改用模块感知方式（如通过ServiceLoader+provides/uses声明），避免反射遍历触发海量临时类
设计可卸载模块层，释放元空间
类卸载是回收元空间的唯一途径。模块化让批量卸载成为可能，但需满足结构与生命周期约束：
- 将插件、租户、功能开关等动态场景封装为独立 ModuleLayer，使用
ModuleLayer.defineModulesWithManyLoaders()创建，并绑定专用类加载器 - 确保该类加载器仅被模块层持有，外部代码不保留对其或其中
Class对象的强引用（例如全局Map<String, Class>缓存必须清除） - 运行时主动卸载前，调用
System.gc()并配合-XX:+PrintClassHistogramAfterFullGC观察类数量是否下降，验证卸载生效
收紧 JVM 元空间参数，暴露真实问题
模块化解决“该不该加载”，JVM 参数决定“加载后怎么管”。宽松配置会掩盖卸载失败问题：
立即学习“Java免费学习笔记（深入）”；
- 设置合理上限：
-XX:MaxMetaspaceSize=192m（根据实测类总数调整，如 5000 个类约需 80–120MB） - 提前触发 GC：
-XX:MetaspaceSize=96m，使元空间更早进入回收周期，与模块卸载节奏对齐 - 启用容器感知：
-XX:+UseContainerSupport，避免在 Docker/K8s 环境中因内存限制误判导致元空间异常增长
构建轻量级运行时镜像，剔除冗余基础模块
模块化支持在构建阶段裁剪整个 JRE，直接减少启动内存与常驻开销：
- 用
jlink构建最小化运行时：只包含应用实际用到的模块，例如jlink --add-modules java.base,java.logging,com.example.core --output jre-min - 避免打包完整 JDK，典型 Web 应用经
jlink裁剪后 JRE 体积可从 200MB+ 降至 40–60MB，启动时加载类数减少 40% 以上 - 搭配 GraalVM Native Image 进一步消除 JIT 和元空间，适用于边缘或实时场景（注意反射/动态代理需显式注册）
