构建长驻型Agent服务时，内存曲线缓慢爬升、Full GC间隔越来越短，最终抛出OutOfMemoryError，是线上最常见也最棘手的问题之一。绝大多数情况下，这并非堆空间真的不够用，而是某些对象被意外持有，垃圾回收器无法回收它们。理解对象引用机制与GC回收策略，是彻底解决这类问题的钥匙。
一、先弄清楚：对象为什么回收不掉
Java（以及大多数托管语言）判断对象是否存活，采用的是可达性分析：从GC Roots出发，沿着引用链遍历，能到达的对象视为存活。GC Roots包括线程栈中的局部变量、静态变量、常量、JNI引用等。只要一条引用链意外地一直连着某个对象，哪怕业务上早已不再使用它，GC也不会回收。
Agent程序的特殊性放大了这个问题。Agent往往是事件驱动、长生命周期的进程，会注册大量回调、监听器和拦截器，如果注销逻辑缺失，这些回调对象连同它们捕获的整个对象图都会被静态注册表持有。比如下面这段典型的问题代码：
public class EventRegistry {
// 静态Map随注册次数无限增长，且从不移除监听器
private static final Map<String, AgentListener> LISTENERS = new ConcurrentHashMap<>();
public static void register(String key, AgentListener listener) {
LISTENERS.put(key, listener);
// 缺少：会话结束后移除监听器的逻辑
}
}每次会话注册一个监听器，会话结束后却不移除，静态Map里的条目只增不减。监听器通常还会捕获会话上下文、消息历史等大对象，泄漏速度非常快。类似的场景还包括：无上限的本地缓存、ThreadLocal在任务切换后未调用remove、内部类持有外部类引用、以及Connection、Stream等未关闭的资源。
二、用工具定位泄漏源头，而不是靠猜
定位泄漏要靠证据链。第一步用jstat观察GC行为，确认到底是泄漏还是容量不足：
# 每秒打印一次GC情况，观察老年代占用趋势 jstat -gcutil <pid> 1000
如果Old区使用率在每次Full GC后逐次抬升，例如从40%涨到55%再涨到70%，这是典型的泄漏特征；如果Full GC后Old区能回落到稳定水位，则更可能是堆配置过小或流量峰值导致。第二步在泄漏发生前后各dump一次堆：
jmap -dump:live,format=b,file=heap1.hprof <pid> # 间隔数小时后 jmap -dump:live,format=b,file=heap2.hprof <pid>
用Eclipse MAT打开两个文件，执行对比功能，观察哪些类的实例数增长最多。随后对可疑对象执行Path to GC Roots（排除弱引用和软引用），MAT会直接画出从GC Roots到泄漏对象的完整引用链，一眼就能看出是哪个静态字段、哪个线程栈或哪个集合在持有对象。这一步是从猜到证的转折点，绝大多数泄漏都能在MAT里找到明确答案。
补充一个容易被忽略的检查点：如果使用JNI或者第三方原生库（如某些向量检索引擎的Java绑定），Native内存泄漏不会体现在Java堆里，需要结合Native Memory Tracking（-XX:NativeMemoryTracking=summary加jcmd ）来排查。
三、从代码层面根治：引用设计与缓存上限
确认引用链后，修复方式取决于业务语义。对于允许被回收的缓存类引用，改用弱引用或软引用是常见手段。WeakHashMap中的Entry在键对象不再被强引用时会被自动清理；也可以显式使用WeakReference包装监听器：
public class EventRegistry {
private static final Map<String, WeakReference<AgentListener>> LISTENERS =
new ConcurrentHashMap<>();
public static void register(String key, AgentListener listener) {
LISTENERS.put(key, new WeakReference<>(listener));
}
public static void dispatch(Event e) {
LISTENERS.entrySet().removeIf(entry ->
entry.getValue().get() == null); // 顺便清理已失效条目
}
}注意弱引用并非万能药。如果业务代码同时持有强引用，WeakReference并不会让对象回收更快，问题依旧存在；而当缓存的语义是内存不足时可丢弃时，软引用可能更合适。更稳妥的方案是给缓存加容量上限与过期策略，Caffeine的maximumSize加expireAfterAccess组合能同时限制内存占用和清理陈旧条目，比裸用HashMap可靠得多。
ThreadLocal泄漏则要在任务结束时严格调用remove，最佳实践是放在finally块中，确保异常路径也能清理。对于线程池场景，由于工作线程长期存活，ThreadLocalMap中的Entry虽然键是弱引用，但值是被ThreadLocalMap间接强持有的，不remove就永远无法回收，这是线程池框架下最常见的泄漏形态。
四、GC调优：让Agent的长驻进程更稳
修完泄漏后，还需要通过GC调优保障稳定性。对4GB以上堆的长驻服务，推荐G1收集器。G1把堆划分为多个Region，通过-XX:MaxGCPauseMillis设置期望停顿目标，默认200毫秒。Agent这类低延迟场景可以适当调小到100毫秒，但要注意目标过小会导致并发标记频繁、CPU开销上升。
重点防范两个问题：一是to-space exhausted（晋升失败），表现为GC日志中出现to-space exhausted字样，本质是Mixed GC速度跟不上对象晋升速度，可以通过增大-XX:InitiatingHeapOccupancyPercent的触发灵敏度（例如从45降到35）、调大-XX:G1ReservePercent或直接扩堆来缓解；二是Humongous对象，G1中大对象直接进入老年代连续Region，若Agent中有巨大的字节数组（如整段对话历史序列化缓冲），考虑拆分或改用流式处理。
java -Xms8g -Xmx8g -XX:+UseG1GC \
-XX:MaxGCPauseMillis=100 \
-XX:InitiatingHeapOccupancyPercent=35 \
-XX:G1ReservePercent=15 \
-XX:+HeapDumpOnOutOfMemoryError \
-XX:HeapDumpPath=/data/dumps/ \
-jar agent-server.jar务必把-Xms和-Xmx设成一致，避免运行期堆伸缩带来的额外停顿；同时开启HeapDumpOnOutOfMemoryError，让OOM自动留下现场，方便事后用MAT分析。最后提醒一点：GC调优只能延缓和缓解，不能治本。如果老年代使用率持续单调上升，任何参数都救不了，答案一定在引用链里。先修代码，再调参数，顺序不能反。