儘管HttpServletResponse.sendRedirect方法和RequestDispatcher.forward方法都可以讓瀏覽器獲 得另外一個URL所指向的資源，但兩者的內部運行機制有着很大的區別。下面是HttpServletResponse.sendRedirect方法實現 的請求重定向與RequestDispatcher.forward方法實現的請求轉發的總結比較：
（1）RequestDispatcher.forward方法只能將請求轉發給同一個WEB應用中的組件；而 HttpServletResponse.sendRedirect 方法不僅可以重定向到當前應用程序中的其他資源，還可以重定向到同一個站點上的其他應用程序中的資源，甚至是使用絕對URL重定向到其他站點的資源。如果 傳遞給HttpServletResponse.sendRedirect 方法的相對URL以“/”開頭，它是相對於整個WEB站點的根目錄 ；如果創建RequestDispatcher對象時指定的相對URL以“/”開頭，它 是相對於當前WEB應用程序的根目錄 。
（2）調用HttpServletResponse.sendRedirect方法重定向的訪問過程結束後，瀏覽器地址欄中顯示的URL會發生改 變，由初始的URL地址變成重定向的目標URL；而調用RequestDispatcher.forward 方法的請求轉發過程結束後，瀏覽器地址欄保持初始的URL地址不變。
（3）HttpServletResponse.sendRedirect方法對瀏覽器的請求直接作出響應，響應的結果就是告訴瀏覽器去重新發出對 另外一個URL的訪問請求，這個過程好比有個綽號叫“瀏覽器”的人寫信找張三借錢，張三回信說沒有錢，讓“瀏覽器”去找李四借，並將李四現在的通信地址告 訴給了“瀏覽器 ”。於是，“瀏覽器”又按張三提供通信地址給李四寫信借錢，李四收到信後就把錢匯給了“瀏覽器”。可見，“瀏覽器”一共發出了兩封信和收到了兩次回覆，“ 瀏覽器”也知道他借到的錢出自李四之手。RequestDispatcher.forward方法在服務器端內部將請求轉發給另外一個資源，瀏覽器只知道 發出了請求並得到了響應結果，並不知道在服務器程序內部發生了轉發行爲。這個過程好比綽號叫“瀏覽器”的人寫信找張三借錢，張三沒有錢，於是張三找李四借 了一些錢，甚至還可以加上自己的一些錢，然後再將這些錢匯給了“瀏覽器”。可見，“瀏覽器”只發出了一封信和收到了一次回覆，他只知道從張三那裏借到了 錢，並不知道有一部分錢出自李四之手。
（4）RequestDispatcher.forward方法的調用者與被調用者之間共享相同的request對象和response對象，它們 屬於同一個訪問請求和響應過程 ；而HttpServletResponse.sendRedirect方法調用者與被調用者使用各自的request對象 和response對象，它們屬於兩個獨立的訪問請求和響應過程 。對於同一個WEB應用程序的內部資源之間的跳轉，特別是跳轉之前要對請求進行一些前期預 處理，並要使用HttpServletRequest.setAttribute方法傳遞預處理結果，那就應該使用 RequestDispatcher.forward方法。不同WEB應用程序之間的重定向，特別是要重定向到另外一個WEB站點上的資源的情況，都應該 使用HttpServletResponse.sendRedirect方法。
（5）無論是RequestDispatcher.forward方法，還是HttpServletResponse.sendRedirect方法，在調用它們之前，都不能有內容已經被實際輸出到了客戶端。如果緩衝區中已經有了一些內容，這些內容將被從緩衝區中清除。
(6) 代碼的執行:
無論是 request.getRequestDispatcher(path).forward(request, response)還是response.sendRedirect,程序都會在執行完該句的情況下繼續向下執行,因此在必要的時候應該使用return終止該方法.
對於 request.getRequestDispatcher(path).forward(request, response),在執行完該方法的時候再進行對request的操作已經沒有任何意義,如果在該方法之後再進行request.setAttribute(),該值將不會被放進當前請求的request中.
response.setRedirect:該方法執行之後,接下來的方法也會被執行.但是使用該方法的時候,會發送一個全新的request,將不再使用原先的request,因此不論在該方法執行之前,還是在該方法執行之後,對request操作,都是無效的.
http://blog.csdn.net/sky840505/archive/2009/01/05/3714909.aspx