选择合适的垃圾回收器
根据应用场景选择匹配的GC器是优化基础。G1GC（-XX:+UseG1GC）适用于大内存（≥6GB）、对延迟有一定要求的场景（如微服务、电商系统），通过划分Region实现可预测停顿；ZGC（-XX:+UseZGC）针对超低延迟设计（目标≤10ms），适合实时数据分析、高频交易系统；Parallel GC（-XX:+UseParallelGC+-XX:+UseParallelOldGC）以高吞吐量为目标，适合后台批处理、科学计算等能容忍较长停顿的场景；CMS（-XX:+UseConcMarkSweepGC）曾用于Web服务器等响应时间敏感场景，但已逐渐被G1/ZGC取代。
合理配置堆内存与分代比例
-Xms（初始堆）和-Xmx（最大堆）设置相同值（如-Xms8g -Xmx8g），避免运行时动态调整带来的性能损耗；-XX:NewRatio调整（如-XX:NewRatio=3表示年轻代占1/4，老年代占3/4），年轻代过大易导致频繁Minor GC，过小则增加Full GC概率；-XX:SurvivorRatio设置（如-XX:SurvivorRatio=8表示Eden区占80%，每个Survivor区占10%），控制对象从Eden晋升到老年代的阈值（-XX:MaxTenuringThreshold，默认15，可根据对象存活周期调整）。优化GC线程数量
-XX:ParallelGCThreads设置并行收集的线程数，建议等于CPU核心数（如8核设置为8），充分利用多核提升GC效率；-XX:ConcGCThreads设置并发标记阶段的线程数，通常为并行线程数的1/4（如-XX:ConcGCThreads=2），避免过多线程抢占应用资源。调整GC停顿时间目标
对于延迟敏感应用，通过-XX:MaxGCPauseMillis设定期望的最大停顿时间（如-XX:MaxGCPauseMillis=200表示允许200ms停顿），GC器会自动调整堆大小和回收策略以接近该目标（如G1会根据此值动态选择回收的Region数量）。
监控GC行为与分析日志
-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:/var/log/gc.log参数，记录GC时间、类型（Minor/Full GC）、回收前后堆大小等信息；jstat -gcutil <pid> 1000实时查看GC次数、停顿时间占比；用VisualVM、Java Mission Control分析GC日志，识别频繁Full GC、停顿过长等问题；jmap -dump:live,format=b,file=heapdump.hprof <pid>生成堆转储文件，通过MAT、YourKit等工具分析内存占用情况。代码层面减少GC压力
StringBuilder替代+拼接字符串），使用对象池（如Apache Commons Pool）复用昂贵对象；ArrayList替代LinkedList（随机访问多）、HashMap替代TreeMap（无序场景））；null），避免内存泄漏；减少长生命周期对象持有短生命周期对象（如静态集合中存储临时对象）。系统级优化辅助
/etc/sysctl.conf，增加vm.swappiness（如设为10，降低系统使用swap的倾向）、net.core.somaxconn（如设为65535，提升网络连接能力）；通过ulimit -n 65535增加文件描述符限制，适应高并发场景；sync; echo 3 > /proc/sys/vm/drop_caches清理pagecache、slab等缓存，释放内存供Java应用使用。