内存泄露，原因很多，因此，不同的情况有不同的解决办法。
首先：说说本项目可能存在的内存泄露的原因。
1：多线程，资源变量的读取，死循环（本程序不存在死循环。。）
2：资源没有释放完全，当然，本程序是由事件驱动，呵呵，原因有可能是由于事件没有正确释放造成的。。。
对于第2种：事件的没正确释放，是指什么呢？
比如说：如下的代码
public class EventTest1:IDisposable {
private int[] testArr = new int[100000000]; public event TestDelegate TestDelegate = null; protected void OnTest()
{ if (TestDelegate != null) { TestDelegate();
} } public void Add() { SystemEvents.DisplaySettingsChanged += SystemEvents_DisplaySettingsChanged; OnTest(); } void SystemEvents_DisplaySettingsChanged(object sender, EventArgs e) { }
IDisposable 成员
}
除非您显示代用Dispose这个方法，不然，绝对会出现内存泄露。。。
因此，为了解决内存泄露，考虑了3种办法：
1：再编写一个服务程序，每天定时关闭和重启内存泄露的服务程序。
可行性描述：
（1）：这样做，最简单，最有可能达到效果的办法。为什么说是最有可能达到效果呢？原因在于，如果用服务程序来重新启动或者关闭一个服务程序的话，有可能关闭和启动的之间得时间过短，后面启动的服务程序，显示出的内存占用，还是那么多。。。。到底是什么原因造成这样的情况，还在研究中。。。
（2）：虽然这样最简单，但是，是最没办法的办法，不推荐使用，况且，就算解决问题后，自己没能够获得多少经验和能力提升。
（3）：除非您的客户要求您马上解决内存泄露的问题，不然，请别采用这个方法
2：最正宗也最符合开发设计思想的办法，重构代码，及时释放掉需要释放的资源
可行性描述：
（1）时间问题：当出现内存泄露后，客户当然是希望能够最快时间得到开发组已经解决问题的确认，显然，重构一个程序，把代码全部在重新清理一遍，显然不是一下就能够完成的。
解决问题：
（1）：在这，也就说说Dispose模式了（不知道到底有没有这个模式，好象自己看的java与设计模式上没看到过。。）。
Dispose模式，代码简单，但是，方法绝对的经典。
#region 释放资源 ，实现 IDisposable bool mIsDisposed = false; public void Dispose() { Dispose(true); GC.SuppressFinalize(this); } protected void Dispose(bool disposing) { if (!mIsDisposed) { if (disposing) { DisposeOverride(true); } DisposeOverride(false); mIsDisposed = true; } } protected virtual void DisposeOverride(bool p) { if (p) { // 释放托管资源 } else { // 释放非托管资源 } } #endregion析构函数： this.Dispose(false);
当然，如果您程序里面所有的该释放的资源都释放了，还有内存泄露，那。。。我也没办法。。。。
3：使用应用程序域
引用官方的话，给点曙光：
使用应用程序域隔离可能终止进程的任务。如果正在执行任务的AppDomain的状态变得不稳定，则可以卸载AppDomain，但不会影响进程。当进程必须不重新启动而长时间运行时，这一点很重要。还可使用应用程序域隔离不应共享数据的任务。
如果程序集被加载到默认应用程序域中，则当进程运行时将无法从内存中卸载该程序集。但是，如果打开另一个应用程序域来加载和执行程序集，则卸载该应用程序域时也会同时卸载程序集。使用此技术最小化长时间运行的进程的工作集，这些进程偶尔会使用大型 DLL。
最后一句话，没看懂，但是，只要第一句，就足够了。。
本人也是第一次使用AppDomain这东西，因此，只能给出代码了：
1：首先，把所有的业务代码等，都用一个类封装起来。
2：开启一个新的AppDomain。
Type testType = Type.GetType("BoCo.Hubei.HuangShi.AlarmLocation.Server.BtsAlarmLocationService");
Assembly ass = testType.Assembly;
string exeAssembly = ass.FullName;
AppDomainSetup ads = new AppDomainSetup();
ads.ApplicationBase =
AppDomain.CurrentDomain.BaseDirectory;
ads.DisallowBindingRedirects = false;
ads.DisallowCodeDownload = true;
ads.ConfigurationFile =
AppDomain.CurrentDomain.SetupInformation.ConfigurationFile;
userCreateAppDomain = AppDomain.CreateDomain("BoCo.Hubei.HuangShi.AlarmLocation.Server.exe", null, ads);//吗的，实在是没明白，这样建立的一个AppDomain后，在新的AppDomain中，用AppDomain.CurrentDomain.FriendlyName取得的名字，怎么会被截去了后面4位，搞得我在这个名称后，加了.exe
ObjectHandle objectHandle = userCreateAppDomain.CreateInstance(exeAssembly, "BoCo.Hubei.HuangShi.AlarmLocation.Server.BtsAlarmLocationService");
BtsAlarmLocationService btsAlarmLocationService = (BtsAlarmLocationService)objectHandle.Unwrap();
对于第1，3种方法，只是治标不治本，只是第3种比第1种，高深了那么一点点。。。。
本文中，所有的代码等，只提供了一个思路，程序到底怎么操作，是您说了算。。。
当然，为了国庆能够安心放假，本程序也就只有采用第3种方法，况且，没使用过的方法，当然要用下。
最后，说下为什么本程序会出现内存泄露而没解决掉的原因：
1：客户原因
本程序实现的功能，在局方来说，是第一次，因此，局方人员希望快速出结果，可以向领导汇报，来增加其业绩。
2：本公司原因
（1）项目经理在明知道程序没有测试完全的情况下，也催促开发组提供程序上线运行测试，结果，上线后，程序的任何一个小小的修改，都需要经过局方领导签字确认后，才能够实施，况且，恰逢奥运，一个签字流程走下来，时间花费太多。。。
（2）项目经理没有认识到本系统对局方使用人员业绩上带来的影响，程序某天只要出现丁点问题，则局方当天的使用人员将暴跳如雷。。。
3：开发组原因
当然，这个是最重要的。
（1）开发组组长没有强势的态度去左右项目经理不上没有测试通过的程序。
（2）开发组组员代码编写能力以及系统的全面考虑上，还存在一定问题。
废话一堆，也只是先以简单办法解决当前问题。
