高并发场景下jvm内存调优核心是让对象“生得合适、死得及时”，需固定堆大小（-xms=-xmx，推荐物理内存50%～70%，单实例≤16gb）、合理分代（-xmn占1/3～2/5，高创建率服务可设40%）、按sla选gc器（如g1/zgc）、配齐元空间、栈、直接内存上限及oom快照与详细gc日志。
高并发场景下 JVM 内存参数调优，核心是让对象“生得合适、死得及时”，减少 GC 干预、压低停顿、防住 OOM。不能靠堆内存堆大就完事，必须结合业务对象生命周期、QPS 峰值和硬件资源做针对性配置。
堆大小与分代比例要稳且准
避免运行中动态扩容缩容引发抖动：-Xms 和 -Xmx 必须设为相等值，推荐为物理内存的 50%～70%，单实例不建议超过 16GB（过大反而延长 GC 扫描时间）。例如：-Xms8g -Xmx8g。
- 新生代（-Xmn）占堆的 1/3～2/5；高创建率服务（如 API 网关、下单入口）可设至 40%，比如 8G 堆配 -Xmn3g
- 用 -XX:NewRatio=2（默认）控制老年代/新生代比例；若观察到大量对象快速晋升老年代，可调小至 1，扩大年轻代空间
- -XX:SurvivorRatio=8 保持 Eden 区主导；短生命周期请求多时，可调成 6，增大 Survivor 容量，多扛几轮 Minor GC，减少提前晋升
按延迟目标选对垃圾回收器
不是并发高就一律上 G1 或 ZGC，得看 SLA 要求：
- 响应敏感型（如支付、订单接口，TP99
- 极致低延迟（TP99
- 吞吐优先型（如批量报表、日志聚合）：Parallel GC 更稳，用 -XX:+UseParallelGC -XX:ParallelGCThreads=实际可用核数×0.8
元空间、栈和直接内存不能漏
这些区域出问题一样触发 OOM，但错误提示隐晦，容易误判：
- 元空间必须设上限：Spring Boot 类多、热更新频繁的服务，-XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=768m；否则 CGLIB 代理、动态类生成会无节制吃内存
- 线程栈（-Xss）：传统线程池若线程数超 1000，可从默认 1M 降至 256k～512k；但需压测验证，低于 256k 易 StackOverflowError
- 直接内存（Netty/NIO 常用）：不走 GC，靠 Cleaner 异步回收，不可控。务必加 -XX:MaxDirectMemorySize=1g，并监控 java.nio.BufferPool.direct.used 指标
必须配齐可观测性兜底项
没日志、没快照的调优等于蒙眼开车：
- OOM 自动抓 dump：-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/data/jvm/dump/heap.hprof
- 详细 GC 日志（JDK 11+）：-Xlog:gc*,gc+age=trace,safepoint:file=/data/jvm/logs/gc.log:time,tags,level,pid
- 禁用显式 GC：-XX:+DisableExplicitGC，防止代码里 System.gc() 扰乱节奏
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
