Java 应用部署：JDK 版本与 JVM 内存参数

不少 Java 应用上线后内存忽高忽低，甚至半夜被系统杀掉，追到底往往是 JVM（Java 虚拟机）参数没有和机器内存对齐。这篇把 JDK 版本选择和内存参数两个点讲清楚。 一、JDK 版本怎么选 优先选 LTS（长期支持）版本：8、11、17。新项目建议直接上 17，垃圾回收和启动性能都有明显改进；老项目先确认所用框架的最低要求，在测试环境跑通再升级。服务器上用 java -version 确认实际生效的版本；一台机器装了多个 JDK 时，再用 which java 和 JAVA_HOME 环境变量核对。常见的坑是系统自带版本过旧、和构建工具要求冲突，先看构建日志里的版本要求再动手装。 二、-Xmx 与机器内存的关系 -Xmx 是 Java 堆的上限，但 JVM 进程吃的内存不止堆：元空间、线程栈、直接内存、GC 自身的开销都在堆外。裸机部署时，堆上限给到机器内存的一半到三分之二比较稳，比如 4G 内存设 -Xmx2g 到 -Xmx2.5g，剩余留给系统和堆外内存。推演一个反面例子：2G 的小机器设 -Xmx1.8g，看似"用满不浪费"，实际上系统加堆外内存一起逼近上限，很容易触发系统的 OOM Killer 把进程直接杀掉，应用连报错日志都来不及打。容器环境同理，内存限制值和 -Xmx 之间要留出同样的余量；JDK 10 之后能感知容器的限制，但显式设置仍然是好习惯。另外，看到内存吃紧就盲目调小 -Xmx 是常见误操作，结果是 GC 变得频繁、响应时间上涨，调参前先分清涨的是堆内还是堆外。 三、OOM 时留下证据 堆内存溢出（OOM，OutOfMemoryError）时自动转储，事后才有得分析： -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/data/dump/ GC 日志也一并打开：JDK 8 用 -XX:+PrintGCDetails，JDK 11 以上用 -Xlog:gc*:file=/data/log/gc.log。出了问题拿着 dump 文件和 GC 日志去定位，比现场重启丢失现场强得多。 四、一点建议 参数调整一次只动一处，观察一两天再继续，出了问题才知道是哪个改动引起的。改过的参数记录在应用的部署文档里，换机器迁移时照抄，别靠回忆。