.NET虽然拥有强大易用的垃圾回收机制，但并不是因为这样，你就可以对资源管理放任不管，其实在稍不注意的时候，可能就造成了资源泄露，甚至因此导致系统崩溃，到那时再来排查问题就已经是困难重重。
一、知识点简单介绍
常见的资源泄露有：
- 内存泄漏：非托管资源没有释放、非静态对象注册了静态实例。
- GDI泄露：字体。
- 句柄泄露：Socket或线程。
- 用户对象泄露：移除的对象未释放。
二、具体实例
1. 内存泄漏
很常见的现象是分不清哪些对象需要释放，对于控件、Stream等一些非托管资源也只管新增，却没有释放，功能是实现了，却埋了颗不小的雷。
private void button1_Click(object sender, EventArgs e)
{
for(int i=0;i<1000;i++)
this.Controls.Add(new TabPage());
}
private void button1_Click(object sender, EventArgs e)
{
new Form2.ShowDialog();
}
如果你觉得写这样的代码很Cool，很简洁，你在项目中也有这么写代码，那你就碰到大麻烦了，你试试在上面Form2中开个大一点的数组来检查内存，然后运行，按几下按钮，你就会发现，内存一直增加，即使你调用了GC也无济于事。所以，对于此类非托管资源要记住释放，用完即废可以采用using关键字。
public Form2()
{
InitializeComponent();
MyApp.FormChanged += FormChanged;
}
上面这个例子中，MyApp是一个静态类，如果在实例对象中向这种类里面注册了事件，而又没有取消注册，这样也会遇到大麻烦，即使在外部已经记得调用了Form2的Dispose也是没用的。
解决方案
- 注意托管资源和非托管资源的释放区别，非托管资源是需要手动释放的。
2. GDI泄露
一般会跟字体相关，例如我曾在Android上用Cocos2d做一个小游戏时频繁地切换字体、Dev控件的Font属性赋值也会有这种现象。
XXX.Font = new Font(...)
解决方案
- 这个问题我目前是采用字体池来解决，类似线程池的概念，相同Key值取同一个对象。若有更好方案欢迎留言讨论
3. 句柄泄露
一般跟Socket和Thread(线程)有关
for(int i=0;i<1000;i++){
new Thread(()=>{
Thread.Sleep(1000);
}).Start();
}
解决方案
- Socket的场景暂时没遇到。
- 线程问题采用线程池相关的辅助类能有效解决，例如ThreadPool、Task、Parallel。
4. 用户对象泄露
一般跟移除的对象未释放有关
private void button1_Click(object sender, EventArgs e)
{
tab.Remove(tabPage);
}
三、最后特别奉送一个内存释放的大招
[DllImport("kernel32.dll", EntryPoint = "SetProcessWorkingSetSize")]
public static extern int SetProcessWorkingSetSize(IntPtr process, int minSize, int maxSize);
/// <summary>
/// 释放内存
/// </summary>
public static void ClearMemory()
{
GC.Collect();
GC.WaitForPendingFinalizers();
if (Environment.OSVersion.Platform == PlatformID.Win32NT)
{
SetProcessWorkingSetSize(System.Diagnostics.Process.GetCurrentProcess().Handle, -1, -1);
}
}
调用以上API能让你的内存一下爆减，是不是很给力，一调用内存就降下来了。But，先别高兴太早，这其实是伪释放，只是暂时解决内存大量泄漏导致系统崩溃的应急处理方案。具体原因参考：
四、总结
实际上由于各个开发人员的水平跟接触面不同，又没有经过统一的培训（各个人对资源释放的理解与关注度不同，或者写代码时就没考虑内存未被释放这种问题），发现问题的时候项目往往已经做到了一个阶段，系统也比较庞大了，这种时候才发现内存泄露的问题确实是很头疼的。
- 资源泄露的场景往往是相互关联的，发生最多的就是内存泄漏，而除了写法可能有问题外，也可能是因为句柄泄露或用户对象泄露引起的。
五、参考资料
转载：
https://www.cnblogs.com/yokeqi/p/11920706.html
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
我实在不愿意提起这个话题.后来在网上看到几篇文章,深深感觉到,已经有程序员站出来,揭穿这个忽悠了千百万用户的诡计了...
附2篇文章的地址:
http://blog.csdn.net/biku/archive/2006/07/06/886038.aspx
http://blog.csdn.net/zlt982001/archive/2005/08/28/466879.aspx
我这篇文章无非是归纳了几篇文章的内容,并深入的阐明恶意使用该技术带来的坏处.
请一味追求低内存软件的用户们注意了:什么才应该是选择软件的主要因素.
物理内存和虚拟内存
物理内存,在应用中,自然是顾名思义,物理上,真实的插在板子上的内存是多大就是多大了.看机器配置的时候,看的就是这个物理内存.
如果执行的程序很大或很多,就会导致物理内存消耗殆尽.为了解决这个问题,Windows中运用了虚拟内存技术,即拿出一部分硬盘空间来充当内存使用,当内存占用完时,电脑就会自动调用硬盘来充当内存,以缓解内存的紧张.
一个程序,不可避免地要用到虚拟内存,因为不频繁执行或者已经很久没有执行的代码,没有必要留在物理内存中,只会造成浪费;放在虚拟内存中,等执行这部分代码的时候,再调出来.
Windows 的任务管理器可以帮助我们看到进程的虚拟内存.调出任务管理器,点击菜单“查看”－“选择列”,在出现的窗口中,钩上“虚拟内存大小
一个程序到底应该使用多少虚拟内存呢?不一定,但是应该以恰到好处的符合虚拟内存原本作用为最好.
下面将揭穿表面看起来调用了大量图片、大量运行库的程序,为什么才“占用”不到 1 MB 的内存的诡计.
原来是 SetProcessWorkingSetSize 函数
MSDN 对该函数的表述(翻译):使用这个函数来设置应用程序最小和最大的运行空间,只会保留需要的内存.当应用程序被闲置或系统内存太低时,操作系统会自动调用这个机制来设置应用程序的内存.应用程序也可以使用 VirtualLock 来锁住一定范围的内存不被系统释放;当你加大运行空间给应用程序,你能够得到的物理内存取决于系统,这会造成其他应用程序降低性能或系统总体降低性能,这也可能导致请求物理内存的操作失败,例如:建立 进程,线程,内核池,就必须小心的使用该函数.
也就是说,该函数不是节省内存,而是强制把进程的物理内存搬到虚拟内存中.
另外有一些资料上说,该函数“将有可能导致缺页中断,严重影响性能”.
函数原型:
BOOL SetProcessWorkingSetSize(
HANDLE hProcess,
SIZE_T dwMinimumWorkingSetSize,
SIZE_T dwMaximumWorkingSetSize
);
我们用 VB 来做这么一个简单的例子,是程序占用 300 KB 内存吧.
建立一个标准的 VB 工程,在 Form1 中放置一个 Timer1 ,把 Interval 属性设置为 1000 (即 1 秒).然后在代码编辑框中输入以下代码:
Private Declare Function SetProcessWorkingSetSize Lib "kernel32" (ByVal hProcess As Long, ByVal dwMinimumWorkingSetSize As Long, ByVal dwMaximumWorkingSetSize As Long) As Long
Private Declare Function GetCurrentProcess Lib "kernel32" () As Long
Private Sub Timer1_Timer()
SetProcessWorkingSetSize GetCurrentProcess(), 50000, 100000
End Sub
然后生成 工程1.exe,执行,调出任务管理器查看,发现内存占用才 320 KB.如果把定时器关闭,这进程的内存一般 4 MB左右.
必须定时执行该函数,否则虚拟内存会慢慢被调出来,恢复原来的内存大小.
如果要使一个本来需要占用大量内存的程序减低到几百 KB ,使用同样的方法即可.
诡计带来的危害
如果 SetProcessWorkingSetSize函数被正常使用,是非常有用处的.但是为了蒙骗用户的眼睛,每秒,甚至几十毫秒就把大量内存往虚拟内存里面压,就会带来无可预计的危害.看看这篇文章怎么说:“因为他只是暂时的将应用程序占用的内存移至虚拟内存,一旦,应用程序被激活或者有操作请求时,这些内存又会被重新占用.如果你强制使用该方法来设置程序占用的内存,那么可能在一定程度上反而会降低系统性能,因为系统需要频繁的进行内存和硬盘间的页面交换.”.
没错,如果你使用了这类软件,意味着你的硬盘将每秒将 I/O 大量数据;硬盘的磁针将拼命旋转...(当然硬盘磁针不可能不旋转^_^,只是选择得更厉害而已).
不是说 BT 很伤内存吗?不然,因为现在大多 BT 软件都有缓存技术.且看 Bitcomet 官方对缓存技术的说明:“传统BT高速下载时硬盘会响得很厉害,这是大量的随机读取造成的.... BitComet可以由用户设置缓存大小.... 可以明显地看出牺牲一小部分内存作缓存对硬盘的保护作用.”
是不是有种心寒的感觉?一类软件宁愿牺牲内存,也要减少保护硬盘;而另外一类软件,却为了欺骗用户,让CPU、硬盘更加奔波......
抓一个凶手
这类软件不少,我以其中一个桌面工具为例,揭穿它的假面具(不点名字了).运行该软件后,随意操作一下,然后打开进程管理器,把虚拟内存列调出来,找到该进程,如图3:
OK,20 MB 虚拟内存,而只有 632 KB 物理内存.细心的你会发现,大概每 1 秒,该行都有闪烁的感觉,没错,这正是每秒调用 SetProcessWorkingSetSize的结果.另外,我们打开 Norton Process Viewer ,查看该进程的 CPU 占用情况,如图4:
可以看到,就算没有操作该软件,但是每秒,都有 3% 的CPU占用起伏(虽然这并不能说明什么).另外,内存框中可以看到物理内存和虚拟内存的占用,两者相去甚远.此外,可以用 Hook API 技术来证明每秒调用 SetProcessWorkingSetSize 的行为.
应该怎么做
这篇文章只想让用户了解软件占用资源的实际.而程序员应该把下功夫,真正从代码中减少内存的消耗,而不是一味忽悠用户.调用 SetProcessWorkingSetSize会带来某些好处,但是何时调用、如何调用应该符合两个要求:
1,在程序暂时不被使用的时候(例如最小化);
2,物理内存和虚拟内存应处于一个合适的比例(而不是 600 KB 比 20 MB 这么荒唐);
3,或者不调用,让 Windows 去处理.
转载：