servletContext接口是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");
来得到这个用户名。
