Servlet_Context接口是Servlet中最大的一个接口，呈现了web应用的Servlet视图。ServletContext实例是通过 getServletContext()方法获得的，由于HttpServlet继承Servlet的关系GenericServlet类和HttpServlet类同时具有该方法。_

条件：假设说我们有一个WEB应用，这个WEB应用中有10个SERVLET

在这里，这个WEB应用就拥有一个它自己的仓库-ServletContext，而这10个Servlet则共享这个大仓库，并且各自拥有属于他们自己的小仓库-ServletConfig。

ServletContext就是一个全局的概念，它属于应用，但我们有时候不想让某些参数被其他Servlet应用，仅仅想在自己的Servlet中被共享，这时候就需要把它保存在ServletConfig中，换句话说，从一个Servlet来看，ServletConfig是它的全局，而从一个Servlet集合（Web应用）来看，ServletContext是它的全局。

假设现在要运行一个应用。

1.Tomcat启动→读入xml文件

2.容器为这个应用建立一个新的ServletContext实例，应用的所有部分都共享这个上下文

3.如果xml中有定义上下文的初始参数，则容器首先创建初始参数实例（应该就像一个Bean一样）

4.把初始化参数实例的引用交给ServletContext

5.容器建立一个新的servlet，这时建立一个新的ServletConfig对象，并且为这个ServletConfig对象提供一个ServletContext的引用

6.调用servlet的init（）方法初始化servlet

由第5步可以看出，每个servlet中都有一个上下文（ServletContext）的引用，因此，servlet都知道这个上下文。

但是ServletContext的实例比Servlet先诞生，所以ServletContext诞生的时候并不知道Servlet的存在。

在JAVA EE API文档中

ServlectContext拥有获得Servlet的方法

例如：Servlet getServlet(String name)

但是，这一类的方法已经废弃了，从注释中可以看出，原先的这些方法返回的值是null，也就是无法获得servlet

因此，ServlectContext诞生的时候并不知道Servlet的存在，它的诞生仅仅是因为容器诞生了

个人觉得，ServletContext中并没有Servlet的信息，相反，每个Servlet中都持有ServletContext的引用。

在HeadFirstJSP中有一个说法我觉得不错，ServletContext就像一块布告栏，你可以往上贴布告，走过的人都可以看到它！

servlet上下文，是针对servletconfig而提出来的，因为容器在配置文件中提取的初始化参数保存在了servletconfig对象中，但由于初始化参数只针对某个具体的servlet而言，别的servlet是访问不到这个参数的，所以为了提供一个可以供全体servlet使用的对象--这个对象也可以从配置文件中获取参数，哪个老外就弄出了一个servletcontext对象，并把它称为上下文或者应用上下文，其实就这么简单。只不过大家现在所听到的所看到的上下文被形态化了，经典话了而已。追起本质，还是很好理解的。

ServletContext 与application的异同

相同：其实servletContext和application 是一样的，就相当于一个类创建了两个不同名称的变量。在servlet中ServletContext就是application对象。大家只要打开jsp编译过后生成的Servlet中的

_jspService()方法就可以看到如下的声明：

ServletContextapplication = null;

application= pageContext.getServletContext();

不同：两者的区别就是application用在jsp中，servletContext用在servlet中。application和page

requestsession 都是JSP中的内置对象，在后台用ServletContext存储的属性数据可以用

application对象获得。

而且application的作用域是整个Tomcat启动的过程。

例如:ServletContext.setAttribute("username",username);

则在JSP网页中可以使用 application.getAttribute("username");

来得到这个用户名。