由于时间比较紧张我就不排版了,但是对于每一种可能的情况都会出对应的代码示例以及解决方案代码示例。
内存泄漏可能的原因之一在于用户在动态分配一个内存空间之中,忘记将这部分内容手动释放。例如:(c++之中使用new分配内存没有使用delete释放,或者c语言使用malloc分配内容没有使用free释放)
#include<iostream>
using namespace std;
int main(){
int* num=new int(10);
return 0;
}
这部分内容没有对num进行delete内存释放,导致内存泄漏。
需要注意的是内存泄漏并不是内存直接漏出去,而是指部分应该被回收的内存没有被回收或者错误的被跳过导致没有正确的回收,导致内存越来越多占据了大量的内存空间,可分配的内存越来越少,影响性能。
如何避免:
通过手动释放这部分内容:
#include<iostream>
using namespace std;
int main(){
int* num=new int(10);
delete num;
return 0;
}
内存泄漏的原因二:没有书写析构函数,导致一部分动态分配的内存没有被释放或者析构函数被遗漏调用。例如基类的析构函数没有被派生类重写,导致当通过基类指针删除派生类时,只调用了基类的析构函数,派生类本身的一部分动态分配的内存没有被释放,导致一部分内容没有被正确的释放,这是析构函数被遗漏时可能发生的情况。解决方法:添加析构函数或者在书写成虚方法的析构函数对其进行方法重写。
#include<iostream>
using namespace std;
class Test{
private:
int* num;
public:
Test(){
num=new int(10);
}
~Test(){
delete num;
}
};
int main(){
Test test;
return 0;
}
原因三:使用的内存被循环的引用,导致引用计数始终不为0,例如使用智能指针shared_ptr,当两个类相互的调用对方的智能指针时,引用计数始终不为0,这部分内容不会被正确的释放。例如:
#include<iostream>
#include<memory>
using namespace std;
class B;
class A{
public:
shared_ptr<B> b_ptr;
};
class B{
public:
shared_ptr<A> a_ptr;
};
int main(){
shared_ptr<A> a=make_shared<A>();
shared_ptr<B> b=make_shared<B>();
a->b_ptr=b;
b->a_ptr=a;
return 0;
}
始终持有对方的智能指针的引用,引用计数始终不清零。
更改建议:可以使用weak_ptr打破循环引用:
例如:
#include<iostream>
#include<memory>
using namespace std;
class B;
class A{
public:
shared_ptr<B> b_ptr;
};
class B{
public:
weak_ptr<A> a_ptr;
};
int main(){
shared_ptr<A> a=make_shared<A>();
shared_ptr<B> b=make_shared<B>();
a->b_ptr=b;
b->a_ptr=weak_ptr<A>(a);
return 0;
}
原因四:程序虽然正确的书写了delete对内容进行释放,但是被异常抛出的错误跳过了内存释放,导致内存释放的部分被跳过,没有正确的释放这部分内存空间,举例说明:
#include<iostream>
#include<stdexcept>
using namespace std;
void func(){
int* num=new int(10);
throw runtime_error("Exception");
delete num;
}
int main(){
try{
func();
}
catch(const exception& error){
cout<<error.what()<<endl;
}
return 0;
}
这部分由于抛出异常被跳过内存释放,我们可以使用智能指针unique_ptr,使其在异常抛出之后自动的释放这一部分内存,就不会发生这种异常,举例说明:
#include<iostream>
#include<memory>
#include<stdexcept>
using namespace std;
void func(){
unique_ptr<int> u=make_unique<int>(10);
throw runtime_error("Exception");
}
int main(){
try{
func();
}
catch(const exception& error){
cout<<error.what()<<endl;
}
return 0;
}
原因5:资源管理对象的生命周期不当,没有在正确的时机管理释放内存。
老规矩,作为一名unity开发程序员,我们来思考C#之中存在哪一些内存泄漏(简单说一下吧,之前在博客之中有详细的描述)
C#之中如果事件订阅未被取消也会导致内存泄漏,所以我们说事件的添加和移除应该是成双成对出现的。另外一些使用lambda表达式的委托无法安全的移除,这时候尽量不要使用lambda表达式防止内存泄漏。另外一个静态变量无法被内存回收,如果静态变量引用了一些对象,这部分内容是无法被垃圾回收的。
C#相对于C++的内存泄漏问题比较少,这是由于C#的自动垃圾回收机制,会自动对一部分内存进行回收,大大降低了内存泄漏的风险,对于C++来说错误遗漏没有进行delete释放或者使用delete释放之后又使用了已经被释放的内容会出现悬空指针的问题。
C#的内存泄漏排查也相对于C++来说比较容易。不过,在使用非托管资源(如文件、网络连接等)时,仍需要手动管理资源的释放。