Q内存占用持续上涨时，应该先从哪些现象判断是否存在内存泄漏？如果应用运行一段时间后内存占用一直不降，重启后又恢复正常，我该怎么初步判断这是不是内存泄漏？
A先通过运行特征判断是否存在泄漏
可以观察几个典型现象：内存曲线是否持续上升且没有明显回落、GC 频率是否越来越高、应用响应是否逐渐变慢、在相同业务负载下内存是否比平时更高。若重启后内存恢复正常，而随着请求量增加又不断增长，通常说明存在对象未被释放或长期被持有的情况。
Q没有专业监控平台时，如何在本地或测试环境快速发现内存异常来源？我手头没有完善的监控系统，只能在本地或者测试环境排查，怎样更快缩小内存问题范围？
A借助基础工具先缩小排查范围
可以先用系统自带的任务管理器、top、ps 等工具观察进程内存变化，再结合语言运行时提供的基础诊断能力查看堆内存、线程数、对象数量和 GC 情况。把问题复现到测试环境后，记录不同业务操作前后的内存变化，能更快判断是某个接口、某类对象还是某段任务逻辑导致的异常增长。
Q生成堆转储文件后，怎样更高效地找出可疑对象？我已经拿到了 heap dump，但对象很多，看起来很复杂，应该重点看哪些信息才能更快定位问题？
A通过对象数量和引用链找出高风险对象
可以重点关注占用内存高的对象类型、数量异常增长的集合容器，以及被谁持有的引用链。优先查看重复出现的大对象、缓存类结构、静态变量引用、线程局部变量和监听器列表。借助分析工具查看 Dominator Tree、Retained Size 和引用路径，通常能较快发现真正阻止对象回收的根源。
Q如果怀疑是缓存或集合使用不当导致的泄漏，应该怎么验证？项目里用了缓存、Map、List 这些结构，我担心是它们没有正确清理导致内存越积越多，如何验证这个判断？
A检查集合增长趋势和清理策略
可以先统计缓存或集合的元素数量是否会无限增长，再检查是否有过期机制、容量上限和淘汰策略。对于 Map、List、Set 这类容器，要确认是否把临时数据长期保留在内存中，或者是否因为 key 设计不合理造成对象无法释放。必要时可以在关键路径增加日志或埋点，观察元素数、命中率和清理次数，验证是否存在持续累积的问题。