Spring MVC 使用閃存屬性

為支持flash屬性，Spring MVC提供了兩個抽象。FlashMap被用來存儲flash屬性，而用FlashMapManager來存儲、取回、管理FlashMap的實例。

對flash屬性的支持默認是啟用的，并不需要顯式聲明，不過沒用到它時它絕不會主動地去創(chuàng)建HTTP會話（session）。對于每個請求，框架都會“傳進”一個FlashMap，里面存儲了從上個請求（如果有）保存下來的屬性；同時，每個請求也會“輸出”一個FlashMap，里面保存了要給下個請求使用的屬性。兩個FlashMap實例在Spring MVC應用中的任何地點都可以通過RequestContextUtils工具類的靜態(tài)方法取得。

控制器通常不需要直接接觸FlashMap。一般是通過@RequestMapping方法去接受一個RedirectAttributes類型的參數(shù)，然后直接地往其中添加flash屬性。通過RedirectAttributes對象添加進去的flash屬性會自動被填充到請求的“輸出”FlashMap對象中去。類似地，重定向后“傳進”的FlashMap屬性也會自動被添加到服務重定向URL的控制器參數(shù)Model中去。

匹配請求所使用的flash屬性

flash屬性的概念在其他許多的Web框架中也存在，并且實踐證明有時可能會導致并發(fā)上的問題。這是因為從定義上講，flash屬性保存的時間是到下個請求接收到之前。問題在于，“下一個”請求不一定剛好就是你要重定向到的那個請求，它有可能是其他的異步請求（比如polling請求或者資源請求等）。這會導致flash屬性在到達真正的目標請求前就被移除了。

為了減少這個問題發(fā)生的可能性，重定向視圖RedirectView會自動為一個FlashMap實例記錄其目標重定向URL的路徑和查詢參數(shù)。然后，默認的FlashMapManager會在為請求查找其該“傳進”的FlashMap時，匹配這些信息。

這并不能完全解決重定向的并發(fā)問題，但極大程度地減少了這種可能性，因為它可以從重定向URL已有的信息中來做匹配。因此，一般只有在重定向的場景下，我們才推薦使用flash屬性。