根据个人经验，我一般是这样验证改善效果的，运行程序，各个功能跑一遍，确保没有改出问题，完全退出程序，手动触发GC，然后通过adb shell dumpsys meminfo packagename -d查看Activivites和Views的数量是否趋近于0；如果不是0，通过Leakcanary检查可能存在内存泄露的地方，继续通过MAT分析，周而复始，改善到自己满意为止。

    最近有人跟我反映主机上一个wordpress插件的使用过程中经常会出现错误，打开了php的dispaly_error功能之后，发现其报“Fatal error: Allowed memory size of 35389440 bytes exhausted(tried to allocate 1406507 bytes) in xxxxxx on line xxx”，意思是致命错误，内存被耗尽了。Google上搜索了一下，网上有很多这样的问题，答案也都一样，更改php的内存限制，把php.ini中的memory_limit改为更大的数值。

     在压测 代码在线运行 工具的时候，发现当并发比较高的时候程序占用的内存会飙升，而且在中断压测之后，内存占用并没有回落。 第一个能想到的办法就是去看代码，但是大多数时候，自己写的代码，很难review出太多的问题；于是就借助golang的pprof来定位问题。

     简介: 了解前端内存泄露原理，最常见的“循环引用”导致的内存泄露原因解析，以及业务项目中存在的内存泄露现象解析。

    昨天我们发现每日构建的服务器突然在一个晚上内存暴增了 8 G ，显然是发生了内存泄露。之前，我们在 skynet 里留下了许多调试协议，使我们很快的确定了发生泄露的服务：在一张地图的 lua State 中。可以确定是地图的 lua 实现中，有些 lua 对象在不断的生成。生成速度不快，但确实没有人解开引用，导致内存持续增长。

    简要说明一下，imgsrc上部署的是apache模块，cdn通过其来访问tfs，并且做一些图像处理工作。有内存泄露是在线上发现的，内存不停的在涨。要找到问题所在，首先需要能够在线下重现，知道在什么情况下会泄露。线上系统当然不可能用valgrind来跑啦，还好我们有tcpcopy(赞一下网易的 @wangbin579 同学，真是个好东西)，我们可以将线上流量镜像到跑着valgrind的机器上来，从而重现问题。跑了一晚上之后问题重现了，这时候需要做的是找到具体能触发问题的http请求。在访问日志和错误日志的帮助下，可以重放这些请求，这样就可以随时重现。一个晚上的访问日志有80多万条之多，我注意到其中有43条是在做图像处理时失败的。这些请求的原图往往都是一些不合法的或已损坏的图。先从这43个请求入手，运气不错，问题已经重现了。这告诉我们多注意一下不法分子总是好的。接下来就是使用2分法来找到具体的某一个访问，可以用脚本来干。最终确定是一个png图片。

    我们正在开发的类数据库系统有一个内存模块，出现了一个疑似”内存泄露”问题，现象如下：内存模块的内存释放以后没有归还操作系统，比如内存模块占用的内存为10GB，释放内存以后，通过TOP命令或者/proc/pid/status查看占用的内存有时仍然为10G，有时为5G，有时为3G, etc，内存释放的行为不确定。 首先说一下内存模块的内存管理机制。我们的内存管理很简单，使用全局的定长内存池，每一个内存块为64KB，如果申请的内存小...

    Javascript有没有内存泄露？如果有，如何避免？鉴于最近有好几个人问到我类似的问题，看来大家对这部分内容还没有系统的研究过，因此，打算在这里把个人几年前整理的一些资料和大家分享...