Java项目内存飙高主因是JVM堆外内存未限制，需同时配置-Xmx、-XX:MaxMetaspaceSize、-XX:MaxDirectMemorySize，并在Docker中启用-XX:+UseContainerSupport。
为什么加 -Xmx 参数后 Java 项目内存还是飙高？
宝塔面板里部署的 Java 项目（比如 Spring Boot），即使在启动脚本里写了 -Xmx512m，实际 top 或面板进程列表中仍显示占用 1.5G+ 内存——这不是 JVM 堆内存超限，而是 JVM 整体内存（堆 + 元空间 + 直接内存 + 线程栈等）叠加导致的。JVM 默认元空间（-XX:MaxMetaspaceSize）无上限，G1/CMS 垃圾回收器还会预留额外内存，线程数多时栈空间（-Xss）也会快速累积。
- 务必同时限制堆、元空间、直接内存三者：例如
-Xmx512m -XX:MaxMetaspaceSize=256m -XX:MaxDirectMemorySize=128m - Spring Boot 2.3+ 默认启用 G1，若项目小且稳定，改用
-XX:+UseSerialGC可显著降低内存驻留（尤其适合单核低配服务器） - 宝塔「软件商店 → Java 项目」配置页里填的“JVM 参数”仅作用于启动命令，但若你用的是自定义 Shell 脚本或 systemd 服务，该配置不生效——得去对应脚本里手动改
宝塔 Java 项目管理页里怎么正确填写 JVM 启动参数？
进入宝塔面板 → 「软件商店」→ 找到已安装的「Java 项目」→ 点击「设置」→ 拉到最下方「JVM 参数」输入框。这里填的参数会拼接到 java -jar 命令前，但注意：不能换行、不能含注释、不能漏空格。
- 正确示例：
-Xms256m -Xmx512m -XX:MaxMetaspaceSize=256m -XX:+UseSerialGC - 错误写法：
-Xmx512m, -XX:MaxMetaspaceSize=256m（逗号多余）；-Xmx512m-XX:MaxMetaspaceSize=256m（缺空格） - 如果项目用了 Log4j2，加上
-Dlog4j2.formatMsgNoLookups=true可防 JNDI 注入，顺便减少部分反射开销 - 修改后必须点「保存」再点「重启项目」，仅保存不重启，参数不会加载
用 ps aux | grep java 验证参数是否生效
参数填完重启后，别急着看宝塔内存图表——它统计的是 RSS（常驻内存），包含 JVM 堆外内存，容易误判。先确认 JVM 实际加载了哪些参数：
- 执行
ps aux | grep java，找到你的项目进程，检查输出中是否完整出现你填的-Xmx、-XX:MaxMetaspaceSize等 - 若只看到
-Xmx512m但没MaxMetaspaceSize，说明面板配置未保存成功，或被项目内置的java -jar xxx.jar --spring.profiles.active=prod启动方式覆盖 - 更准的验证方式是进项目根目录运行：
java -XX:+PrintFlagsFinal -version | grep -E "MaxHeapSize|MaxMetaspaceSize"，看默认值是否被覆盖（需 JDK 8u191+）
为什么限制了堆内存，docker stats 或 htop 还是显示高内存？
如果你把 Java 项目跑在 Docker 容器里（哪怕宝塔装了 Docker 插件），JVM 默认无法感知容器内存限制，会按宿主机总内存计算堆大小比例（如 -XX:InitialRAMPercentage），导致疯狂申请。这是最隐蔽的“参数写了却无效”的原因。
- 必须显式加
-XX:+UseContainerSupport（JDK 8u191+/10+ 默认开启，但旧 JDK 需手动加） - 推荐组合：
-XX:+UseContainerSupport -XX:MaxRAMPercentage=75.0，比硬写-Xmx更适配容器弹性伸缩 - 宝塔 Docker 插件部署时，若镜像基于 openjdk:8-jre-slim，大概率没开
UseContainerSupport，建议换openjdk:11-jre-slim或更高
真正卡住的点往往不在堆大小本身，而在元空间泄漏、Netty 的直接内存缓存未释放、或者 JVM 对容器边界的无知——这些不会报 OOM，但会让 RSS 持续爬升到触发系统 kill。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
