對於這一塊,也只是用到了 Web 開發的相關技術,而且不少技術已通過時或者被民間更好的取代,因此側重於最基礎的 Servlet API、會話機制。java
頂級接口:Servlet、ServletConfig、ServletContextweb
最經常使用的類:HttpServletapi
廣義上說,一個類實現了 Servlet 接口那麼就稱這個類是 Servlet,也就是說 該接口中定義了全部 servlet 都必須實現的方法 。瀏覽器
方法一覽:tomcat
根據官方 API 的解釋,簡單翻譯過來就是這麼個意思:服務器
Servlet 是一個運行在服務器端的小的 JAVA 程序,Servlet 接受和響應來自客戶端的請求(一般是 HTTP協議);網絡
爲了實現該接口,能夠繼承 javax.servlet.GenericServlet
也能夠繼承 javax.servlet.http.HttpServlet
.app
該接口定義了初始化、處理請求、刪除 Servlet 的方法,這些方法被稱做生命週期方法,以以下的順序調用:webapp
init()
方法初始化service
方法處理destroy
方法銷燬資源,等待 GC 回收除了生命週期方法以外該接口還提供了一個 getServletConfig 方法,Servlet 得到一些啓動信息。this
ServletConfig 的對象是由容器構造的。
初始化 Servlet 的時候,該對象傳遞一些啓動的參數給 Servlet (以 init() 方法參數的形式)
能夠簡單理解:ServletConfig 中封裝了 web.xml 中給 Servlet 配置的參數 ( <init-param>
)
方法一覽:
Servlet 和 ServletConfig 是一一對應的,一個 Servlet 都跟着一個 config 對象
Servlet 上下文封裝了與 Servlet 所在容器通訊的一些方法。
對此其實應該很熟悉,是咱們經常使用的四大存儲域之一,是範圍最大的一塊。
ServletContext 與容器對應的;一個 ServletContext 能夠對應多個 Servlet.
其中定義了不少經常使用的方法,好比獲取絕對路徑的 getRealpath,存儲數據的 get/set Attrbiute.
得到 ServletContext 的集中方式:
PS:既然 ServletConfig 能夠拿到,那麼它的實現類也都是能夠的~
它實現了以前說的 Servlet 和 ServletConfig 接口,可是畢竟是個抽象類,只有一個方法未實現,因此上面有八個方法均可以使用,此外還有他本身的一些方法。
下面說說重要的幾個:
init(ServletConfig)
默認的實現能夠總結爲兩句:{this.config = config;init();}
,能夠看出此類確定有個 ServletConfig 類型的屬性,在 init 中進行保存 config 的引用方便後續方法的使用。
而後直接又調用了一個空參的 init 方法,這個方法就是 GenerciServlet 本身定義的,默認空實現,若是有本身的初始化邏輯,重寫這個空參方法便可,而且不須要再調用 super.init(config)
方法。
abstract service(ServletRequest, ServletResponse)
是的,惟一的一個抽象方法,惟一的一個未實現的。
服務器收到請求會調用 service 進行處理,怎麼處理也應該由開發者去實現,注意參數爲 ServletRequest,通常咱們須要強轉成 HttpServletRequest ,通常也就是處理 Http 請求吧。
而後還有兩個打印日誌的方法,這就是所有的方法了。
它繼承自 GenericServlet ,並實現了它未實現的 service 方法,從名字能夠看出是專門處理 Http 請求的,開發者寫的 Servlet 通常也是繼承自這個類。
而後它實現的方法作了兩件事:
那麼,它本身定義的這個 service 方法到底幹了什麼呢?
簡單說就是經過 request.getMethod()
獲取到請求方式,而後根據這個請求方式來分別調用 doXXX 方法,因此開發者通常都會重寫其 doGet 和 doPost。
PS:protected 修飾的方法能夠覆蓋,可是權限不能變小。
從實現者、調用者、構造者的角度來看就是:
API名字 | 實現者 | 調用者 | 構造者(new) |
---|---|---|---|
Servlet | 開發者 | 容器 | 容器 |
ServletConfig | 容器 | 開發者 | 容器 |
ServletContext | 容器 | 開發者 | 容器 |
Request | 容器 | 開發者 | 容器 |
Response | 容器 | 開發者 | 容器 |
RequestDispatcher | 容器 | 開發者 | 容器 |
Cookie | 容器 | 開發者 | 開發者 |
HttpSession | 容器 | 開發者 | 容器 |
Filter | 開發者 | 容器 | 容器 |
Listener | 開發者 | 容器 | 容器 |
服務器以 Tomcat 爲例,那麼一個請求的過程大概能夠分爲下面幾步:
服務器啓動階段
Tomcat 啓動時檢測自身配置文件 conf 目錄,若是配置有問題,則沒法啓動。
Tomcat 檢查 webapps 下工程的全部的 web.xml 文件,若是該文件有問題,則 tomcat 報錯,啓動正常(報錯的工程沒法訪問,其餘工程能夠正常使用)。
瀏覽器地址欄輸入地址,回車
瀏覽器將地址信息打包成標準的 HTTP 請求字符串
若是輸入的是域名,那麼進行 DNS 解析,而後經過網絡發送到服務器地址
服務器接受到請求並解析,將請求信息打包到 HttpServletRequest/response 對象中
到 web.xml
中尋找指定的 url-pattern
,根據 servlet-name 找到 Servlet-class
容器檢測內存中是否有該 Servlet 的對象,若是有則使用原來的對象,若是沒有則使用反射構造 Servlet 對象
【沒有找到對象】容器調用 init() --> 方法初始化
容器調用 service(ServletRequest) --> doXx
咱們重寫 DOXxx 方法 完成業務邏輯
容器將 response 對象轉換成標準的 HTTP 響應字符串,再經過網絡回送給瀏覽器
瀏覽器接受標準的響應信息,解析,顯示
固然上面的每一步其實還能夠細分,可是這裏就先不分的過於細了。