jvm内存与gc优化核心是匹配对象生命周期与业务sla：web api重低延迟（选g1/zgc，控-xx:maxgcpausemillis），批处理重吞吐（用parallel gc），容器环境严控内存（固定-xms/-xmx、限metaspace）。
Java 应用的 JVM 内存与 GC 优化，核心是让内存分配节奏匹配对象生命周期，同时让回收行为贴合业务 SLA 要求——低延迟服务要控停顿，批处理任务要保吞吐，容器化部署还要防内存超限。
明确目标再动参数
别一上来就调 -Xmx。先问清楚：这应用是 Web API（要求响应快、停顿短），还是离线计算（允许秒级暂停、追求 CPU 利用率）？或是跑在 2G 内存的 Kubernetes Pod 里（必须严控驻留内存）？目标不同，收集器和参数方向完全相反：
- Web/实时系统：选 G1（JDK8u202+）、ZGC（JDK11+）或 Shenandoah（JDK12+），重点压 -XX:MaxGCPauseMillis（如 150ms）
- 后台批处理：用 Parallel GC（-XX:+UseParallelGC），配合 -XX:MaxGCPauseMillis 反而会拖慢吞吐
- 资源受限环境：固定堆大小（-Xms4g -Xmx4g），禁用自动扩容；限制元空间（-XX:MaxMetaspaceSize=256m），防类加载泄漏
堆结构配比要贴合对象行为
新生代不是越大越好，老年代也不是越小越省。关键看对象“活多久”：
Java Development Manual
下载
Java开发手册规约集合，基于阿里巴巴Java开发手册（嵩山版）。 涵盖7大维度：编程规约、异常日志、单元测试、安全规约、MySQL数据库、工程结构、设计规约。 当用户需要：(1) 编写或审查Java代码 (2) 检查命名/代码规范 (3) 处理异常和日志 (4) 编写单元测试 (5) 安全编码 (6) 数据库设...
- 如果日志显示大量对象在 Minor GC 后立刻晋升（-XX:+PrintTenuringDistribution 显示 “age 1” 晋升量大），说明 Survivor 区太小或对象存活率高，可调大 Survivor 比例：-XX:SurvivorRatio=6（Eden:S0:S1 = 6:2:2）
- 若老年代增长缓慢但 Full GC 频繁，可能是新生代太小导致对象“被迫早熟”，尝试增大新生代：-XX:NewRatio=1（老年代:新生代 = 1:1）或直接设 -Xmn2g
- G1 不建议手动设 -Xmn；它靠 -XX:MaxGCPauseMillis 动态调节新生代大小，更关注 Region 分配是否合理（-XX:G1HeapRegionSize=1M 适合中等堆，4M 适合大堆）
用对工具才能看清问题
调参不是猜，得靠真实数据反馈：
- 启动时加 -Xlog:gc*:file=gc.log:time,tags,uptime（JDK10+），生成结构化 GC 日志；用 GCViewer 或 https://gceasy.io 解析，重点关注 “Full GC count/hour” 和 “Total GC time %”
- 运行中查实时状态：jstat -gc -h10
5s 看各代使用率、GC 次数与耗时；若 S0/S1 使用率长期 >90%，说明 Survivor 不够用 - 怀疑内存泄漏？用 jmap -histo:live
看对象实例数TOP10；或 jmap -dump:format=b,file=heap.hprof 后用 VisualVM 或 Eclipse MAT 分析引用链
几个容易忽略但关键的细节
有些参数不起眼，却常成瓶颈：
- TLAB 开关：默认开启（-XX:+UseTLAB），但若应用大量创建极小对象（如 DTO 字段赋值），可加大 TLAB 大小：-XX:TLABSize=1024k，减少线程间锁竞争
-
元空间泄漏：动态代理、热部署（Spring DevTools）、反复 defineClass 都可能撑爆 Metaspace；监控 jstat -gc
中的 M、MU 值，持续上涨就要查类加载器 - 直接内存溢出：NIO 的 ByteBuffer.allocateDirect() 不走堆，但受 -XX:MaxDirectMemorySize 限制（默认等于 -Xmx）；Netty 类应用务必显式设置该值
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
