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");
來得到這個使用者名稱。
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");
來得到這個使用者名稱。