避免内存泄漏和频繁Full GC的关键在于代码、配置、监控三层面协同控制：代码上切断无效强引用，配置上合理划分堆与约束元空间，监控上通过日志与堆分析定位根因。
避免内存泄漏和频繁 Full GC，关键在于理解对象生命周期与堆内存分配逻辑，并在代码、配置、监控三层面协同控制。不是堆越大越好，也不是 GC 越少越优，而是让对象“该活的时候活，该死的时候死”。
代码层面：切断无效强引用
内存泄漏本质是本该被回收的对象被意外持有。最常见的是静态集合、缓存、监听器、线程等长期存活组件持有了短生命周期对象的引用。
- 静态 Map/ConcurrentHashMap 存储业务对象时，必须配套清理机制（如 WeakReference 包装、LRU 驱逐、定时过期）
- 注册监听器、回调、钩子后，务必在资源释放阶段显式注销（onDestroy、finally 块或 try-with-resources）
- 避免在线程局部变量（ThreadLocal）中存放大对象；使用后调用 remove()，尤其在线程池场景下防止跨请求污染
- 自定义数据结构（如环形缓冲、树节点）要检查引用关系是否成环；HashSet/HashMap 的 key 必须正确重写 hashCode() 和 equals()
JVM 配置层面：合理划分与主动约束
错误的堆参数会放大代码缺陷的影响——比如新生代太小，大量对象被迫提前晋升老年代；元空间无上限，动态代理类持续加载终将耗尽。
- 堆初始值与最大值设为相同：-Xms4g -Xmx4g，避免扩容抖动与内存碎片
- 新生代建议占堆 1/3～1/2：-Xmn1536m（4G 堆下），配合 -XX:SurvivorRatio=8 控制 Eden/Survivor 比例
- 元空间必须设上限：-XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=256m，防止类加载失控
- 禁用显式 GC：-XX:+DisableExplicitGC（屏蔽 System.gc()），避免第三方 SDK 或旧代码触发
- 优先启用 G1 收集器：-XX:+UseG1GC -XX:MaxGCPauseMillis=200，兼顾大堆与可控停顿
监控与诊断层面：从现象定位根因
不靠猜，靠指标。Full GC 频繁本身是症状，背后可能是泄漏、错配、或流量突增。需建立分层判断链：
立即学习“Java免费学习笔记（深入）”；
- 用 jstat -gcutil <pid> 1000 观察：O（老年代使用率）持续上升 → 重点查泄漏；M（Metaspace）逼近 100% → 查类加载；S0/S1 长期非零且 EU（Eden 使用率）飙升 → 新生代太小或对象存活时间过长
- 开启 GC 日志：-Xloggc:gc.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps，用 gceasy.io 或 GCViewer 分析 FGC 触发原因（Allocation Failure？Metaspace allocation failure？System.gc？）
- 在老年代使用率达 70%～80% 时抓堆快照：jmap -dump:live,format=b,file=heap.hprof <pid>，用 MAT 分析 Dominator Tree 和 Leak Suspects，看谁占了最多老年代空间
- 结合业务日志交叉验证：FGC 是否集中在某接口调用后？是否与定时任务、批量导入、文件解析等操作时间吻合？
运行环境层面：警惕容器与系统干扰
线上问题常藏在 JVM 之外。K8s 中未设 memory limit、cgroup 内存限制、宿主机 swap 启用、其他进程争抢物理内存，都会导致 JVM 误判可用内存，进而频繁触发 GC。
- K8s Pod 必须设置 resources.limits.memory，并确保 JVM 参数 -Xmx ≤ 该值的 80%，预留空间给元空间、直接内存、线程栈等非堆区域
- 禁止容器内启用 swap：swapoff -a 或启动时加 --memory-swappiness=0
- 检查是否启用了 RMI 默认的分布式 GC：-Dsun.rmi.dgc.client.gcInterval=0 -Dsun.rmi.dgc.server.gcInterval=0，避免每小时自动 Full GC
- 确认没有被监控 Agent（如某些 APM 工具）注入大量字节码或创建全局静态监听器
