C#相比其他语言，拥有强大的垃圾回收机制，但并不是这样，你就可以对内存管理放任不管，其实在稍不注意的时候，可能就造成了内存泄露，甚至因此程序崩溃。
以下是遇到过的内存优化-内存泄露的问题与应对方案。
场景：
- Form.ShowDialog()问题。
private void button1_Click(object sender, EventArgs e)
{
new Form2.ShowDialog();
}
如果你觉得写这样的一段代码很Cool，很简洁，你在项目也有这么写代码，那你就碰到大麻烦了，你试试在Form2中开个大一点的数组来检查内存，然后运行，按几下button1按钮，你就会发现，内存一直增加，即使你调用GC也无济于事。
- 窗体向全局性事件注册了事件的问题。
复制代码
public Form2()
{
InitializeComponent();
MyApp.FormChanged += FormChanged;
}
复制代码
MyApp是一个静态类，如果向这种类里面注册了事件，而又没有取消注册，这样也会遇到大麻烦。即使在外部已经记得调用了Form2实例的Dispose也是没用的。
实际上由于各个开发人员的水平跟接触面不同，又没有经过统一的培训（各个人对内存释放的理解与关注度不同，或者写代码时就没考虑内存未被释放这种问题），发现问题的时候项目往往已经做到了一个阶段（SIT测试），系统也比较庞大了，这种时候才发现内存泄露的问题确实是很头疼的。
解决方案：
-
基于架构师的经验，或者统一意见会议，在开发前对开发人员进行必要的统一培训，对关系到性能、内存等会影响系统稳定性的解决方案进行培训。这本身既有助于开发人员水平的提高，也对系统的稳定性方面提供很大的保障（项目可不是做完一个就没了，这种培训会带来长久的增益效果）。
-
注意托管资源与非托管资源的释放区别，非托管资源是需要手动释放的。
-
使用using关键字，避免忘记Dispose的情况，如上面的ShowDialog问题。（using中还起到了try-catch的作用，避免由于异常未调用Dispose的情况）
-
使用UnLoad事件或者析构函数，对注册的全局事件进行取消注册。
-
特别注意自定义组件的稳定性更重要，发生问题时影响也更广。注意继承IDisposable接口，进行资源释放，并且对有疑问/复杂逻辑的地方添加try-catch语句。（发现问题的人员不一定有权限修改这些组件）一定要保证组件健壮健壮，再健壮。这是我做组件的感悟~~~多么痛的领悟！！
最后特别奉送一个"内存释放"的大招：
调用这个API能让你的内存一下爆减：贴一段网上的示例代码
复制代码
[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);
}
}
复制代码
是不是很给力，一调用内存就降下来。先别高兴太早，这其实是伪释放，只为暂时解决内存大量泄露导致系统崩溃而急需解决的情况。