Java内存调优需按业务特征选GC策略：吞吐优先用Parallel GC，低延迟选G1或ZGC，再结合分代配置、行为监控与参数迭代优化，并防控静态Map等内存泄漏。
Java 应用内存性能调优中，GC 策略不是选一个回收器就完事，而是要匹配业务特征、堆规模、延迟容忍度和硬件资源，再配合分代配置与行为观察持续迭代。
按场景选对回收器
回收器本质是权衡取舍的工具：
- 吞吐优先（如批处理、后台计算）：用 Parallel GC（-XX:+UseParallelGC），它通过多线程并行回收最大化 CPU 利用率，但停顿时间不可控；
- 低延迟敏感（如交易接口、实时推送）：G1 是通用首选（-XX:+UseG1GC），靠 Region 划分和预测模型控制停顿（-XX:MaxGCPauseMillis=200）；ZGC（-XX:+UseZGC）适合堆超大（≥4GB）且要求亚毫秒级停顿的场景，但需 JDK 11+；
- 老系统或小堆（：CMS 已被标记为废弃，不建议新项目使用；Serial GC 仅适用于嵌入式或单核环境。
堆结构必须贴合对象生命周期
默认分代比例（新生代:老年代 ≈ 1:2）常不适用真实流量：
- 短期对象多（如 Web 请求临时 DTO、JSON 解析结果）→ 增大新生代（-Xmn 或 -XX:NewRatio=2），减少 Minor GC 频次；
- 缓存类服务（如本地热点数据缓存）→ 适当扩大老年代，避免频繁晋升触发 Full GC；
- Eden 区过小会加剧 TLAB 竞争，可调 -XX:TLABSize 提升线程本地分配效率；
- 元空间（Metaspace）泄漏易被忽略，尤其动态生成类多时（如 Spring AOP、字节码增强），需设 -XX:MetaspaceSize=256m 并监控增长趋势。
日志驱动调优闭环
所有参数调整必须基于可观测数据，而非猜测：
立即学习“Java免费学习笔记（深入）”；
- 开启基础日志：-Xloggc:gc.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps；
- 关注关键信号：Young GC 耗时是否 >50ms、Full GC 是否每月超过 1 次、老年代占用率是否持续 >75%；
- 用 GCViewer 或 Prometheus + Grafana 可视化趋势，识别“GC 频率突增”或“内存使用阶梯式上升”等异常模式；
- 每次只改一个参数（如先调 -XX:MaxGCPauseMillis，再调 -XX:InitiatingHeapOccupancyPercent），压测验证后再推进下一步。
绕不开的内存泄漏防控
再好的 GC 策略也救不了持续泄漏：
- 静态 Map、缓存未设 TTL、线程局部变量未清理，都会把短命对象“锁”在老年代；
- 用 jmap -dump:format=b,file=heap.hprof pid 抓堆快照，MAT 中看 Dominator Tree 和 Histogram，重点排查 java.util.HashMap$Node、org.apache.catalina.connector.Request 等高频嫌疑对象；
- 资源类泄漏（数据库连接、文件流）需强制用 try-with-resources，监听器注册后务必配套注销逻辑。
