当线上服务出现内存持续增长且疑似与 Dubbo 相关时，你会采用哪些步骤定位泄漏源，并如何针对性地修复？

回答思路

1. 【回答框架 1】内存泄漏通常由未释放的引用或缓存无限增长导致。在 Dubbo 中，常见来源包括：未正确关闭的 ExchangeClient、消费者或提供者端的注册中心订阅缓存、线程池中的任务队列积压、以及序列化/反序列化时产生的大量临时对象未被回收。
2. 【回答框架 2】排查步骤：首先通过 jmap 或 MAT 等工具获取堆转储，分析对象引用链，定位占用内存最大的对象类型；其次结合 Dubbo 的监控指标，观察连接数、线程池活跃度、注册中心通知频率等；再次，通过压测或日志追溯，确认泄漏是否与特定接口、特定调用模式相关。
3. 【回答框架 3】修复方向：对于连接未关闭，确保在异常或关闭时调用 close 方法；对于缓存无限增长，配置合理的过期策略或上限；对于线程池，调整队列大小和拒绝策略，避免任务积压；对于序列化，考虑使用更高效的方式或优化对象结构。
4. 【回答框架 4】修复后需进行验证：通过长期运行监测内存曲线是否平稳，可使用 GC 日志或监控工具确认泄漏已消除。
5. 【关键点 1】利用堆转储和对象引用分析定位内存泄漏源头。
6. 【关键点 2】检查 Dubbo 连接、缓存、线程池和序列化相关对象。
7. 【关键点 3】修复时注重资源的正确释放与缓存策略的配置。
8. 【易错点 1】忽略线程池任务队列导致的隐式内存占用。
9. 【易错点 2】仅通过增加堆内存来掩盖问题，未根治泄漏源。