1 启动参数示例
✅ 一份生产可用的 JVM 参数示例（8G 机器举例）
-Xms4g
-Xmx4g
-Xss512k
-XX:MaxMetaspaceSize=512m
-XX:MaxDirectMemorySize=1g-XX:+UseG1GC
-XX:MaxGCPauseMillis=200
-XX:+ParallelRefProcEnabled-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=/data/logs/heapdump.hprof-Xlog:gc*,gc+heap=info,gc+age=trace
🧠 一、内存相关参数（最核心）
-Xms4g
JVM 启动时的初始堆大小，一上来就分配 4G 堆，避免运行时动态扩容带来的卡顿。
-Xmx4g
JVM 最大堆大小，堆最多就用 4G，通常 Xms = Xmx（生产标配）。
📌 目的：
让堆大小从一开始就固定，GC 行为更稳定、可预测
-Xss512k
每个线程的栈大小，默认很多 JVM 是 1M。
改成 512K：
- 单个线程更省内存
- 能承载更多线程
如果你递归很深的代码很多，才需要调大。
📌 影响：
线程数 × Xss = 一大块内存消耗（而且不算在 Xmx 里）
-XX:MaxMetaspaceSize=512m
类元数据区（Metaspace）最大值，Spring / 代理 / 反射 / CGLIB 很吃这个，不设上限：可能一直涨 → Metaspace OOM 或吃光系统内存，512M 对大多数 Spring 项目都够用了（可按需调）。
-XX:MaxDirectMemorySize=1g
直接内存（NIO / Netty / ByteBuffer.allocateDirect）上限，不走 Java 堆，Netty / MQ / Web 容器 常用，不设：默认可能≈Xmx，容易“偷偷吃内存”。
📌 设上限的好处：
防止 Direct Memory 把系统内存吃爆，但 Heap 看起来还很健康
♻️ 二、GC 相关（稳定优先）
-XX:+UseG1GC
使用 G1 垃圾回收器
适合：
大堆
服务端
追求低延迟、可预测停顿
现在生产基本默认首选（Java 11+ 非常成熟）
-XX:MaxGCPauseMillis=200
期望 单次 GC 停顿不超过 200ms
不是硬保证，是 目标值
G1 会尽量调策略去接近这个目标
-XX:+ParallelRefProcEnabled
并行处理 弱引用 / 软引用 / 虚引用
可以减少 GC 停顿时间
对有大量缓存 / 引用对象的应用很有帮助
几乎“白给的优化”
💥 三、OOM 兜底与排障
-XX:+HeapDumpOnOutOfMemoryError
发生 OOM 时，自动生成堆快照
排查内存泄漏的“命根子”
强烈建议生产必开 ✅
-XX:HeapDumpPath=/data/logs/heapdump.hprof
HeapDump 文件输出路径
确保：
目录存在
磁盘空间够大（可能几个 G）
📜 四、GC 日志（线上必备）
-Xlog:gc*,gc+heap=info,gc+age=trace
打印 GC 相关日志（Java 11+ 语法）
可以看到：
什么时候 GC
每次 GC 前后内存变化
新生代对象年龄分布
是否频繁 Full GC
📌 用来判断：
是不是内存压力大？是不是有泄漏？GC 策略是否合理？
🧩 五、这套配置适合什么场景？
非常适合：
Spring Boot / Spring Cloud
Tomcat / Undertow / Netty
长期运行的服务
对稳定性和延迟有要求的后端服务
⚠️ 一个重要提醒：别把机器内存全给 JVM
比如你是 8G 机器：
建议：
-Xmx4g
剩下给：
OS
Page Cache
Direct Memory
Metaspace
线程栈
容器环境更要留余量，不然容易被 OOM Kill
✅ 最后一句话总结
这套参数的设计目标是：
🎯 堆大小固定、GC 稳定
🎯 限制非堆内存，防止“偷偷吃内存”
🎯 出问题能留下证据（HeapDump + GC 日志）
🎯 适合长期跑的生产服务