为什么不应该重写service方法
轉載自??為什么不應該重寫service方法
故事通常是這樣開始的：?
從前，有一個程序猿，他語重心長地對孫子說：“孩子，要是你以后寫servlet，最好不要重寫service方法啊”?
孫子大為不解，程序猿又說：“聽爺爺的，準沒錯，爺爺的爺爺就是這么說的……”
——為什么不應該重寫service方法呢？
如果你也曾思考過這個問題，但暫時無解，這篇文章或許可以給你一點啟發。
先來看一個具體的例子：
當時我正在osc看紅薯的一篇大作，只見我右手F12熟練的打開了chrome的開發者工具，左手迅猛的按了幾下F5，然后看到了這個結果。
聰明的你一定已經發現，除了第一個名為12_77118的請求返回狀態為200，其他的都為304，那么200和304有什么區別呢？這個稍后解釋。
一切從代碼里面來，我們先拋開理論，看一個具體的code：
我編寫了一個index.html，如下：
<html> <body> <h3>I'm a test page . </h3> <h3>I'm a test page . </h3> <h3>I'm a test page . </h3> <h3>I'm a test page . </h3> <h3>I'm a test page . </h3> <h3>I'm a test page . </h3> <h3>I'm a test page . </h3> </body> </html>我們來訪問這個頁面看看。
這是我第一次訪問這個頁面（表示本地并沒有對這個文件的緩存）：
我們來看看http請求和響應的消息頭：
《圖：一》
為了作為對比，我們再F5刷新一次：
《圖：二》
這次請求的頭信息中多了一條If-Modified-Since，而且返回的響應中，狀態變為了304，這是怎么回事？還記得紅薯那篇文章頁中的304么，你會發現，304多出現在對于靜態資源的請求上面。
原來對于靜態資源來說：
1. 當瀏覽器第一次發起請求時（請求頭中沒有If-Modified-Since），server會在響應中告訴瀏覽器這個資源最后修改的時間（響應頭中的Last-Modified）。（見圖一）
2. 瀏覽器也很聰明，當你再次（點擊鏈接，或者F5，或者回車，但是不能是ctrl+F5）請求這個資源時，瀏覽器會詢問server這個資源自上次告訴我的最后修改時間以來有沒有被修改（請求頭中If-Modified-Since）。（見圖二）
3. 如果資源沒有被修改，server返回304狀態碼，并不會再次將資源發送給瀏覽器，瀏覽器則很知趣的使用本地的緩存文件。（見圖二）
所以所有的靜態資源如果沒有發生變化，通常是不會傳遞多次的，不管什么瀏覽器或者server都應該遵守這種詢問的約定。看起來很爽啊，很智能是不是？這種約定的機制就是?http緩存協商——這是約定優于配置的又一體現。
有了緩存協商的知識，理解為什么我們不應該重寫service就很容易了。還是從代碼出發，這次我們看一個復雜一點的例子：
在這個例子中，我們請求一個控制器（MeServlet），然后轉向一個視圖（index.html），為了簡單起見，web.xml中將只有這個servlet的配置：
<web-app> <servlet> <servlet-name>me</servlet-name> <servlet-class>com.me.web.MeServlet</servlet-class> </servlet> <servlet-mapping> <servlet-name>me</servlet-name> <url-pattern>/test</url-pattern> </servlet-mapping> </web-app>然后是MeServlet：
public class MeServlet extends HttpServlet { @Override protected void service(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException { /** * 1. 處理具體的業務： * -- 處理請求參數 * -- 檢查緩存 * -- 處理具體數據 * -- 更新緩存 */ doBizLogic(req, res); /** * 2. 根據處理的結果轉向具體的視圖： * -- 這里假設就是 index.html */ getServletContext() .getRequestDispatcher("/index.html").include(req, res); } public void doBizLogic(HttpServletRequest request, HttpServletResponse response) { System.out.println("do biz."); } }可以看到，每次F5刷新返回的狀態碼都是200，讓我們看看具體的請求和響應頭：
?
我們發現無論我們如何刷新頁面，每次響應狀態都是200，index.html的內容每次都被完整的發送給瀏覽器，這看起來很笨，為什么不像靜態資源一樣進行緩存協商呢？原因是緩存協商是基于http請求和響應頭中的Modified信息的，如果沒有這個信息，是無法進行緩存協商的。而對于動態內容而言，server無法幫我們決定內容是不是有改變，也無法替我們決定動態內容的最后修改時間。
所以它不會幫我們在響應中加上Last-Modified，我們必須自己來做這件事，我們小小地修改一下MeServlet：
public class MeServlet extends HttpServlet { @Override protected long getLastModified(HttpServletRequest req) { /** * 這里你要自己決定動態內容的最后修改時間，例如你可以返回 * -- 數據緩存最后更新的時間 * -- 簡單起見，我們假設最后的修改時間是 1000 */ return 1000; } @Override protected void service(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException { /** * 1. 處理具體的業務： * -- 處理請求參數 * -- 檢查緩存 * -- 處理具體數據 * -- 更新緩存 */ doBizLogic(req, res); /** * 2. 根據處理的結果轉向具體的視圖： * -- 這里假設就是 index.html */ getServletContext() .getRequestDispatcher("/index.html").include(req, res); } public void doBizLogic(HttpServletRequest request, HttpServletResponse response) { System.out.println("do biz."); } }你會看到getLastModified這個方法是重寫的，說明HttpServlet中已經有了這個方法，我們使用這個方法來告訴server在這個動態資源中，最后內容變化的時間是多少。最理想的情況是server會自己回調這個方法，那就太省心啦。
我們先訪問的看看：發現依然每次都是200，server沒有告訴瀏覽器最后的修改時間，緩存協商機制無法工作。
先別沮喪，忘了我們要解釋什么問題嗎——為什么不要重寫service方法。也許你已經猜到了，如果你看看service方法的實現，現在你已經明白了，service方法自己實現了緩存協商的機制，如果我們重寫它，反而將這中良好的機制給去掉了。
?
我們再修改一下，這次我們重寫doGet，在doGet中完成完全相同的邏輯：
public class MeServlet extends HttpServlet { @Override protected long getLastModified(HttpServletRequest req) { /** * 這里你要自己決定動態內容的最后修改時間，例如你可以返回 * -- 數據緩存最后更新的時間 * -- 簡單起見，我們假設最后的修改時間是 1000 */ return 1000; } @Override protected void doGet(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException { /** * 1. 處理具體的業務： * -- 處理請求參數 * -- 檢查緩存 * -- 處理具體數據 * -- 更新緩存 */ doBizLogic(req, res); /** * 2. 根據處理的結果轉向具體的視圖： * -- 這里假設就是 index.html */ getServletContext() .getRequestDispatcher("/index.html").include(req, res); } public void doBizLogic(HttpServletRequest request, HttpServletResponse response) { System.out.println("do biz."); } }這次在訪問，
終于出現了久違的Last-Modified，再次回車請求頁面，哈哈變成304了。
現在你也許已經清楚了，為什么不應該重寫service方法，似乎是為了保留HttpServlet默認實現的緩存協商的機制；其實還有另外一個原因：就是禁用你沒有在servlet中重寫的方法，例如post、head等，這樣就從一定程度上提高了安全性。
理論到此為止，現在讓我們來看看緩存協商機制有什么實際的好處：
還是紅薯的那邊文章，我們現在全加載（ctrl+F5）一次看看，
?
我們看到總共發起了45個請求，請求的數據量為198.93KB，然后F5刷新一次：
?
這次只有36個請求，數據量只有23.62KB
我們看到這篇文章被9960個id訪問， 而每一個id實際上可能訪問這個頁面多次（像我這樣，實際的數據可能得問問紅薯），然后我們看到很多304靜態資源都是整站通用的：
?
如果你是osc的常客，并且不經常更換瀏覽器，不經常清理緩存，甚至其他人的頭像都可以是通用的，為了簡單起見，我們這里考慮每個id都只訪問這個頁面一次，并且假設所有的資源都已經緩存在用戶本地，得出：
（198.93-23.62）×9960 = 1746086.6KB = 1705.1637M = 1.665G。
很驚人吧，這只是一個頁面，別忘了，我們還假設所有的用戶都只訪問一次，你想想osc上面有多少篇博文，加起來……
流量是什么，是銀子啊。
幸運的是，這些省銀子的事情瀏覽器和server都已經幫我們做好了，那我們就不需要關心這個了嗎？？我們看到12_77118這個請求所占用的資源也不少，如果文章再長點，再長點的話……還會更大。
?
如果紅薯愿意，也可以讓這個請求實現緩存協商，可以進一步減少流量。
當然這里的計算并不是完全的精確，實際的情況復雜很多，但是這個計算的量級應該是對的，是值得參考的。
流量涉及的另一個問題就是帶寬，以更小的貸款提供更高的并發是每個站長應該追求的。不過考慮到osc以新聞為主，一次性消費，所以……不過那時題外話了。
好了，如果你有耐心看到這里，我想你也許會對service有了新的理解，為什么我們不應該重寫這個方法。
萬事有例外，如果你需要實現一個前端控制器的話，就是另外一回事了，這留給大家自己思考。
第一次發文，大家開拍吧，：）～～
?
總結
以上是生活随笔為你收集整理的为什么不应该重写service方法的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 26个字母vs上万个汉字，中国人的打字机
- 下一篇： 五分钟轻松了解Hbase面向列的存储