电脑用着用着突然变卡，程序自己崩溃，任务管理器里某个进程的内存占用一路飙升，八成是遇到内存泄漏了。这问题不解决，轻则软件崩，重则系统卡死重启，得赶紧查。
Windows 上怎么查
普通用户先打开任务管理器，点“详细信息”标签页，右键表头选“选择列”，勾上“工作集（内存）”和“提交大小”。运行可疑程序，观察它的内存使用是不是只增不减。如果数字一直涨，基本可以怀疑有泄漏。
要深入排查，得上专业工具。推荐用微软官方的 Process Explorer，这玩意儿比任务管理器强太多。下载后运行，找到对应进程，双击打开属性，切换到“性能”或“堆栈”标签，能看到更细粒度的内存分配情况。如果看到句柄数或私有字节数持续增长，大概率就是它在漏。
开发者还可以用 Visual Studio 自带的诊断工具。调试模式下运行程序，打开“诊断工具”窗口，实时监控内存变化。还能拍下内存快照，对比前后对象数量，直接定位泄漏源头。
Linux 下常用手段
命令行党首选 top 或 htop，按 M 按内存排序，盯住 RES 列。长时间运行的服务如果 RES 一直涨，就得警惕了。
真要动手查，valgrind 是老牌利器。特别是它的 memcheck 工具，能精准抓出 C/C++ 程序里的内存问题。比如你写了个小程序 test.c，编译后执行：
valgrind --leak-check=full ./test它会告诉你哪一行 malloc 了但没 free，甚至能分清“确定泄漏”和“可能丢失”的情况，非常实用。
Java 应用怎么办
Java 虽然有 GC，但对象该释放时不释放，照样内存爆炸。这时候得看堆内存分布。用 jstat 命令观察老年代使用量：
jstat -gc <pid> 1000每秒刷一次，如果老年代一直涨，GC 后也下不来，说明有对象堆积。再用 jmap 导出堆转储文件：
jmap -dump:format=b,file=heap.hprof <pid>然后拿 Eclipse MAT 或 JVisualVM 打开 hprof 文件，查谁占的内存最多，找 GC Roots 路径，很快就能锁定泄漏源。
浏览器页面也不能忽视
现在网页越来越重，一个标签页吃掉几个 G 内存也不是新鲜事。Chrome 开发者工具里的 Memory 面板就能派上用场。打开 DevTools，切到 Memory，点“Take heap snapshot”，多拍几次，看看哪些 JS 对象越积越多。尤其是事件监听、闭包引用这些地方，最容易藏坑。
要是发现某个组件卸载后对象还在，多半是忘记解绑事件或者定时器没清除。这种问题在单页应用里特别常见。
内存泄漏不像崩溃那样立马报警，它是慢慢拖垮系统的慢性病。平时多留意异常的内存增长，早查早处理，别等到系统卡成幻灯片才动手。