页面生成周期中的两个Application池的详情小弟了解

我们知道在asp.net页面的生成周期一开始的时候会调用一次Application对象的Application_start方法，我们都知道这个方法仅仅是在第一次执行的时候调用的，但是我们知道http请求是没有状态的，每次客户来了请求信息之后，经过页面生存周期的话，都会提前去反射编译global文件回去到元数据，生成一个Application对象，并且把他放入Application池中，这个对象维护了我们的请求管道模型，这样看来，客户的每一个请求都会，都会去判断池中有没有Application对象有就取出来，没有就去创建这个对象，这样多个请求，都会有Application对象，那他是怎么让这个Application_start方法仅仅执行一次的那？顿时让我疑惑不解，后来经过仔细查看源代码后，才发现，在整个管道中维护着的并不是一个Application对象，而是两个，一个特殊的Application池，这个池中存放的是特殊的全局的静态的Application对象，同时这个对象也可以存储一些全局的信息例如：我们统计网站在线人数信息使用，而另外的一个普通的Application池中存放的侧是真正维护管道19个事件的Application对象；这样在去想一下我们的管道就顺理成章了；

查看反编译源代码：

从IIS中的扩展程序把请求信息交给.net Framework开始：

首先通过ISAPIRuntime对象的Public int ProcessRequest(IntPrt ecb,int iWRType)，这个方法中一个很牛逼的就是通过扩展程序把请求信息传到这个方法的ecb指针，同时这也是从扩展程序（非托管程序）到.net中的托管程序的一个交界处，这个ecb指针就执行了原始的请求信息的资源，是Windows中的一个资源，

在这个ProcessRequst方法中：wr=ISAPIWorkerRequest.CreateWorkerRequest(ecb,useropp) 把请求信息做了简单的封装到了WorkRequest对象中HttpRuntime.ProcessRequestNoDemand(wr);

最后交给了httpruntime对象的ProcessRequst方法来处理copntext=new HttpContext(wr,false);

在这个方法中又哦他能够给传递来的Workrequest对象创建了上下文对象，上下文对象中封装了完成了请求和响应报文信息HttpRequest和HttpResponse对象

同时IhttpHandler applicationInstance=HttpApplicationFactory.GetApplicationInstance(context)通过工厂创建了HttpApplication对象,进入这个方法GetApplicatioinInstance(context)后发现：_theApplicationFactory.EnsureInited()内部保证了global文件的编译，内部做了判断没有编译的话就编译这个文件，其次_theApplicationFactory.EnsureAppStartCalled(context)保证了Application_Start方法的执行，进入这个方法，里面进行了判断，如果这个方法没有调用，this.FireApplicaioinOnStart(context)就去执行这个方法，这个方法中HttpApplication specialApplicationInstance=this.GetSpecialApplicationInstance();获取了一个特殊的Application实例

其次我们在回到我们的GetApplicatioinInstance(context)方法来 里面的最后提到了return _theApplicationFactory.GetNormalApplicationInstance(context)返回一个NormalApplication实例，让这个实例去维护我们的Application管道，这样看下来就阔然开朗了，终于把疑惑很久的问题解决了。