内存泄漏怎么排查提示词（Node.js / Java / Python 堆快照对比与常见泄漏点）
服务内存一直涨、跑几天就被 OOM 杀掉或越来越慢时用：让 AI 先确认是不是真泄漏，再教你用对应语言的工具抓两次堆快照做对比，最后对照常见泄漏点审查代码。
通用大模型 对话模型通用
你是一名做过大量线上内存问题排查的后端工程师，熟悉 [语言/运行时] 的内存模型和诊断工具。 现状： - 服务类型与部署方式：[服务类型与部署方式]（例：Node.js 接口服务，容器限制 1G） - 内存曲线描述：[如每小时涨 50MB，重启后归零] - 流量特征：[如白天高峰、夜间几乎无请求] - 最近的改动：[最近上线的功能] - 可疑代码或已有的监控截图文字： [粘贴内容] 请分四步回答： 第一步：判断是不是真的泄漏。说明怎么区分「泄漏」和「正常的缓存增长 / 垃圾回收还没触发 / 堆上限设得太大」，比如看流量低谷时内存会不会回落、手动触发 GC 后是否下降、增长是否和请求数成正比。 第二步：给出这个运行时的诊断方法，写出具体命令或操作： - 怎么在测试环境复现（压测脚本思路，跑多久）； - 怎么抓堆快照或内存分析数据，间隔多久抓第二次； - 两次快照对比时看什么：哪类对象数量持续增加、保留它们的引用链（retainer / GC root 路径）是什么。 第三步：对照这些常见泄漏点审查我贴的代码，逐条说明有没有、在哪里： - 全局或模块级的 Map、数组、缓存只增不删，没有上限或过期； - 事件监听、定时器、订阅注册后没有移除； - 闭包长期持有大对象或请求上下文； - 连接、文件句柄、流没有关闭； - 线程局部变量或请求级对象被存进长生命周期的结构里。 第四步：给出修复代码（最小改动），以及上线后怎么确认修好了（看哪个指标、观察多长时间）。 要求：命令要写当前版本真实可用的；对代码的判断标明「确定」还是「可疑，需要快照证实」。
高亮处换成你自己的内容：[语言/运行时]、[服务类型与部署方式]、[如每小时涨 50MB，重启后归零]、[如白天高峰、夜间几乎无请求]、[最近上线的功能]、[粘贴内容]
ChatGPT Plus 充值
已被复制 0 次
使用说明
怎么填变量：[内存曲线描述] 尽量写数字和规律，「重启后归零、每天涨到上限」和「涨到某个值就稳定」是两种完全不同的情况，后者通常只是缓存。容器限制、JVM 的 -Xmx 等参数一定要写上。
常见坑：
- 只抓一次堆快照看不出问题，必须在同样负载下间隔一段时间抓两三次做对比，看「持续增长」的那类对象。
- 进程内的本地缓存（比如用 Map 做的缓存）是最常见的元凶，加上大小上限或改用带淘汰策略的缓存库。
- Python 里 C 扩展分配的内存不一定出现在 Python 层的分析工具中，看不到不代表没有。
追问技巧：拿到快照对比结果后，把「增长最多的前几类对象和引用链」的文字贴回去，问「这条引用链说明是哪段代码持有了对象」。
示例输出
示例，仅供参考（Node.js 接口服务，每小时涨约 50MB）
判断：夜间流量接近零时内存不回落，且增长量和请求数成正比，基本可以确定是泄漏。
抓快照：
bash
# 启动时允许通过信号生成堆快照
node --heapsnapshot-signal=SIGUSR2 server.js
# 压测 10 分钟后发送一次，再过 10 分钟发送第二次
kill -USR2 <pid>在 Chrome DevTools 的 Memory 面板加载两份快照，选「Comparison」视图，按 Delta 排序。
代码审查：
| 泄漏点 | 结论 | 位置 |
|---|---|---|
| 模块级缓存只增不删 | 确定 | userCache 以请求 ID 为键，从不删除 |
| 事件监听未移除 | 可疑 | 每个请求都 emitter.on('done')，需快照证实 |
同款作品
用这条提示词做出来的作品；原作者会因此获得积分
还没有同款，来做第一个。
0 条评论
还没有评论，来抢沙发～