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