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），防类加载泄漏
堆结构配比要贴合对象行为
新生代不是越大越好，老年代也不是越小越省。关键看对象“活多久”：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 如果日志显示大量对象在 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 适合大堆）
用对工具才能看清问题
调参不是猜，得靠真实数据反馈：
立即学习“Java免费学习笔记（深入）”；
- 启动时加 -Xlog:gc*:file=gc.log:time,tags,uptime（JDK10+），生成结构化 GC 日志；用 GCViewer 或 https://gceasy.io 解析，重点关注 “Full GC count/hour” 和 “Total GC time %”
- 运行中查实时状态：jstat -gc -h10 <pid> 5s 看各代使用率、GC 次数与耗时；若 S0/S1 使用率长期 >90%，说明 Survivor 不够用
- 怀疑内存泄漏？用 jmap -histo:live <pid> 看对象实例数TOP10；或 jmap -dump:format=b,file=heap.hprof <pid> 后用 VisualVM 或 Eclipse MAT 分析引用链
几个容易忽略但关键的细节
有些参数不起眼，却常成瓶颈：
- TLAB 开关：默认开启（-XX:+UseTLAB），但若应用大量创建极小对象（如 DTO 字段赋值），可加大 TLAB 大小：-XX:TLABSize=1024k，减少线程间锁竞争
- 元空间泄漏：动态代理、热部署（Spring DevTools）、反复 defineClass 都可能撑爆 Metaspace；监控 jstat -gc <pid> 中的 M、MU 值，持续上涨就要查类加载器
- 直接内存溢出：NIO 的 ByteBuffer.allocateDirect() 不走堆，但受 -XX:MaxDirectMemorySize 限制（默认等于 -Xmx）；Netty 类应用务必显式设置该值
