java垃圾回收调优需围绕系统负载特征，紧扣分代性、stw代价、非实时性三大约束，使gc行为与业务节奏对齐，并通过日志可观测性精准定位真因。
在复杂系统中应用Java垃圾回收高级特性，关键不是堆参数调得越大越好，也不是盲目切换GC算法，而是围绕系统真实负载特征做针对性设计。核心在于理解分代性、STW代价、非实时性这三大约束，并让GC行为与业务节奏对齐。
分代策略要匹配对象生命周期分布
复杂系统往往存在混合型对象：短时API请求产生的临时对象、长周期缓存对象、中间状态聚合对象。不能只靠默认的8:1:1（Eden:S0:S1）比例硬扛。
- 如果监控发现大量对象在Survivor区熬过几次Minor GC后直接晋升老年代（promotion rate高），说明Survivor空间偏小或对象存活时间比预期长，可适当增大SurvivorRatio并启用-XX:+AlwaysTenure（强制晋升）避免反复复制
- 若老年代增长缓慢但Full GC频繁触发，检查是否因CMS或G1的并发标记失败（concurrent mode failure）导致退化为Serial Old；此时应调大-XX:CMSInitiatingOccupancyFraction或-XX:G1HeapWastePercent，给并发标记留出缓冲空间
- 对有明确生命周期的模块（如批处理任务），可用-XX:+UseParallelOldGC配合-XX:MaxGCPauseMillis=200，用吞吐量换可控停顿，避免G1在大堆下出现不可预测的Mixed GC抖动
引用类型要嵌入业务语义
强引用不是唯一选择。合理使用软/弱/虚引用，能把GC从“被动清理”变成“主动协同”。
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 本地缓存场景下，用SoftReference包装缓存值，配合-XX:SoftRefLRUPolicyMSPerMB=1000，让JVM在内存压力上升时自动驱逐，比自己写LRU淘汰逻辑更轻量且与GC节奏一致
- 监听器注册表这类易泄漏结构，用WeakHashMap存储listener→callback映射，避免因忘记反注册导致老年代持续膨胀
- 需感知对象回收时机的场景（如连接池归还、资源释放），用PhantomReference+ReferenceQueue实现无侵入式清理，不阻塞GC线程，也避免finalize()的性能黑洞
GC日志必须成为系统可观测性一环
复杂系统里GC不是独立模块，而是与网络IO、DB连接、线程调度深度耦合。光看GC次数和耗时远远不够。
- 开启-XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:gc.log -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=5 -XX:GCLogFileSize=10M，确保日志包含精确时间戳、各代使用率、晋升大小、GC触发原因（Allocation Failure / Metadata GC Threshold / G1 Evacuation Pause等）
- 将gc.log接入ELK或Prometheus+Grafana，建立“GC Pause > 200ms → 同时段HTTP 99分位延迟突增”的关联告警，而不是孤立监控GC指标
- 对G1，重点关注G1EvacuationPause日志中的“Other”耗时占比——若超过30%，说明Remembered Set更新或Ref Proc成为瓶颈，需调整-XX:G1RSetUpdatingPauseTimePercent
避免把GC当万能解药
很多“GC问题”本质是代码或架构问题。调优前先确认是不是真由GC引发。
- 观察到频繁Minor GC但Eden区使用率始终低于30%，大概率是对象创建速率过高（比如String拼接、JSON序列化未复用ObjectMapper），应优化代码而非调大新生代
- Full GC后老年代占用率下降极少，且伴随大量Finalizer队列堆积，说明存在finalize()阻塞或未关闭的Closeable资源，需走代码审计而非换GC算法
- 服务RT毛刺与GC日志无时间重合，但CPU sys%飙升，可能是JNI调用或锁竞争导致，此时调GC参数毫无意义
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
