疑問的產(chǎn)生
這個疑問是我在寫文件下載的時候產(chǎn)生的，我是用HttpServletResponse獲取到Outputstream，然后利用OutputStream直接寫數(shù)據(jù)的。當(dāng)時我就想這個OutputStream是不是就是對應(yīng)的Socket連接的OutputStream。即是不是的程序在用stream寫的時候，數(shù)據(jù)也同時在發(fā)？
Response的OutputStream把數(shù)據(jù)寫到哪去？
于是我看了下HttpServletResponse的getOutputStream方法，看看它注釋是怎么說的。
/**
* Returns a {@link ServletOutputStream} suitable for writing binary
* data in the response. The servlet container does not encode the
* binary data.
*
* <p> Calling flush() on the ServletOutputStream commits the response.
*
* Either this method or {@link #getWriter} may
* be called to write the body, not both, except when {@link #reset}
* has been called.
*
* @return a {@link ServletOutputStream} for writing binary data
*
* @exception IllegalStateException if the <code>getWriter</code> method
* has been called on this response
*
* @exception IOException if an input or output exception occurred
*
* @see #getWriter
* @see #reset
*/
public ServletOutputStream getOutputStream() throws IOException;
以上，注釋有說明是OutputStream是用來寫響應(yīng)body內(nèi)容的，也有提到flush()方法，說明肯定是有緩沖的，所以應(yīng)該不是直接操作socket寫數(shù)據(jù)。我猜測應(yīng)該是有一個字節(jié)數(shù)組用來暫時存儲，然后統(tǒng)一flush。但是還是不太確定，于是簡單翻閱了下tomcat源碼。
找到ServletOutputStream的實現(xiàn)類CoyoteOuputStream。它實現(xiàn)了OutputStream的抽象方法write，把數(shù)據(jù)寫入到OutputBuffer類型的字段中存著。而這個OutputBuffer對象來自于coyote/Response。其實這個OutputBuffer也只是一個接口，具體實現(xiàn)一直向下翻是StreamOutputBuffer。數(shù)據(jù)大小沒有限制，是用鏈表存儲的，每個鏈表節(jié)點存儲8196字節(jié)。
什么時候把響應(yīng)數(shù)據(jù)報返回給客戶端？
其實就是查看，它是何時調(diào)用OutputBuffer的flush方法的。我逐層查看，最終定位到了connector/Response的finishResponse()方法。這個方法，會先發(fā)送響應(yīng)行和響應(yīng)頭。然后再發(fā)送響應(yīng)body。Tomcat的源碼我看的不多，這里找到一張不錯的時序圖，描述的是一個HTTP請求的處理過程。如下，我們把重點放在servlet的service方法調(diào)用，和Response的fininshResponse方法調(diào)用上?？梢缘玫?，在service方法返回后，執(zhí)行的就是finishResponse操作。也就是說，當(dāng)servlet程序處理完這個請求后，tomcat就會把響應(yīng)結(jié)果發(fā)回客戶端
注意：servlet的程序不參與底層數(shù)據(jù)的收發(fā)，或者說不控制
servlet的service方法調(diào)用在圖中哪里？
包含在ApplicationFilterChain的internalDoFilter方法中。
servlet程序處理請求指的是什么？
根本上servlet程序做的工作就是，根據(jù)Request的信息，填充Response信息而已。
servlet程序與Spring MVC是什么關(guān)系？
Spring MVC底層還是Serlvet，它是把所有請求都用一個servlet處理，這個servlet叫做DispatcherServlet，而它又把請求分發(fā)給對應(yīng)的@RequestMapping標(biāo)注的方法進行處理。整體上來說就是完成一個service方法的調(diào)用。
那MVC的返回頁面，返回REST數(shù)據(jù)是怎么回事？
返回頁面就是把頁面數(shù)據(jù)寫入到響應(yīng)Body中；@ResponseBody注解，實際上就是把@RequestMapping標(biāo)注的方法的返回值轉(zhuǎn)為JSON字符串寫入到響應(yīng)Body中。這里的響應(yīng)Body指的就是前文中的OutputBuffer.
Tomcat與Servlet程序的職責(zé)
《How Tomcat works》中講到，Servlet容器（Tomcat就是一種Servlet容器）的任務(wù)有概括地講有三個
1.創(chuàng)建一個Request對象，并填充相關(guān)信息（parameters、headers、cookie、uri等）
2.創(chuàng)建一個Response對象
3.調(diào)用與此請求關(guān)聯(lián)的Servlet的service方法，把Request和Response傳給它。
這里我用自己的話講一下：當(dāng)瀏覽器向服務(wù)端發(fā)來一個請求時，服務(wù)端會將請求數(shù)據(jù)報的內(nèi)容解析出來，創(chuàng)建一個填充有請求信息的Request對象，同時創(chuàng)建一個"空的"Response對象，然后把這兩個對象傳給servlet的service方法，讓它來完成Response對象的填充，最后把Response數(shù)據(jù)發(fā)送給客戶端。
為什么要傳Request對象？
你不傳Request對象，Servlet程序就不知道該填充什么。換句話說，它不知道你到底想要什么資源。
Tomcat是如何找到請求關(guān)聯(lián)的Servlet的？
我們知道，Tomcat在開發(fā)的時候不可能知道你會往它里面部署什么項目，servlet程序叫什么。所以它不可能硬編碼來調(diào)用service方法，它所使用的就是反射機制。
想想在使用spring boot框架開發(fā)之前，我們是怎么部署項目的？就是把項目打包，然后放到Tomcat的webapp目錄下。跑起來后，項目對應(yīng)的URL就是localhost:8080/projectName/xxx這樣是吧。而且，在項目中，不管是注解式的，還是web.xml式，都會配置Servlet程序的映射。把URL映射到某個Servlet類文件。
當(dāng)請求來臨時，先根據(jù)projectName找到對應(yīng)項目，再根據(jù)后續(xù)的URL映射到對應(yīng)的Servlet類名。之后Tomcat就會利用反射機制加載Servlet類文件，獲取實例，然后再調(diào)用service方法。
coyote/Response、connector/Response、connector/ResponseFacade之間的關(guān)系？
coyote/Response主要就是跟底層的數(shù)據(jù)傳遞掛鉤的，而connector/Response是coyote/Response的上層包裝，它實現(xiàn)了HttpServletResponse接口。但是如果將它直接傳給service方法，則害怕用戶直接將HttpServletResponse強轉(zhuǎn)為connector/Response，直接調(diào)用底層的一些方法。所以引入了一個使用"Facade模式"，將connector/Response除了HttpServletResponse接口定義的public方法都屏蔽掉。也就是說，傳遞給service的實際上是connector/ResponseFacade對象，就算強轉(zhuǎn)為實際類型，也只能看到HttpServletResponse接口定義的方法。
總結(jié)
以上就是這篇文章的全部內(nèi)容了，希望本文的內(nèi)容對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值，謝謝大家對腳本之家的支持。
