这两天一直纠缠内存问题，程序吃内存很厉害，跑一段时间后，内存占用就接近100%了，假死机。反复的查程序，也没发现内存泄漏，就不断的修改内存分配策略，很头疼。
看任务管理器里面的程序内存使用一直都很正常，330m左右，峰值到550m，但是整个系统的内存却在被缓慢的侵蚀，但就是看不出来是那个程序使用了哪么多的内存。后来也是偶尔想到在任务管理器里把程序占用的handles数目也显示出来看，哇，这下问题可出来了，我们的程序使用的handles数目竟然达到上G，这么多的handles当然内存占无数了。
然后就好查了，最后发现不是文件打开忘记关闭了，而是因为我们的一个类里新加了一个线程同步mutex lock作为成员变量，这个东西是构造的时候创建的，然后析构的时候，应该是CloseHandle()来释放，但是一粗心，顺手写了一个ReleaseMutex()，这样这个mutex lock就泄漏了。倒霉的是这个类是一个很基本的基类，基本上我们所有的类都从它派生而来，所以这个handle的泄漏在实际中就多了去了。
修改有二：1，把释放代码改成CloseHandle()；2，把这个mutex设成static。
历史上，这是我第二次遭遇handles leak。
看任务管理器里面的程序内存使用一直都很正常，330m左右，峰值到550m，但是整个系统的内存却在被缓慢的侵蚀，但就是看不出来是那个程序使用了哪么多的内存。后来也是偶尔想到在任务管理器里把程序占用的handles数目也显示出来看，哇，这下问题可出来了，我们的程序使用的handles数目竟然达到上G，这么多的handles当然内存占无数了。
然后就好查了，最后发现不是文件打开忘记关闭了，而是因为我们的一个类里新加了一个线程同步mutex lock作为成员变量，这个东西是构造的时候创建的，然后析构的时候，应该是CloseHandle()来释放，但是一粗心，顺手写了一个ReleaseMutex()，这样这个mutex lock就泄漏了。倒霉的是这个类是一个很基本的基类，基本上我们所有的类都从它派生而来，所以这个handle的泄漏在实际中就多了去了。
修改有二：1，把释放代码改成CloseHandle()；2，把这个mutex设成static。
历史上，这是我第二次遭遇handles leak。
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/67063/viewspace-466119/ ，如需转载，请注明出处，否则将追究法律责任。
上一篇：
jni的小麻烦
下一篇：
没有了~
请登录后发表评论
登录
全部评论
