我在視圖Scoped Bean中有一個方法，帶有@PreDestroy註釋和另一個帶有@PostConstruct註釋。JSF 2.1 ViewScopedBean @PreDestroy方法不叫
每當我瀏覽到使用此視圖範圍的bean的頁面時，都會正確調用@PostConstruct方法。
但是，當我導航到新頁面（不使用此視圖範圍bean）<h:link/>時，將永遠不會調用@PreDestroy方法。
我不是在談論changing manually the url or the end of the session，只是一個導航案例。
我缺少什麼？
在此先感謝
這是設計。只有在POST操作導致導航不是回發到相同視圖的導航時（即操作方法沒有返回null或void，而是完全適用於String，即使只是空白），它也將立即被刪除。
<h:link>生成一個GET鏈接，它不會調用任何POST動作。由於在卸載視圖時不可靠地通過（XML）HTTP請求通知服務器端，因此無法通知JSF銷燬與該視圖關聯的視圖範圍的bean。在這種情況下，只有在會話過期時或會話中的最大邏輯視圖已超出（缺省值爲15）並且關聯的視圖是第一個時纔會銷燬視圖作用域bean。
如果你真的要destoy視圖由導覽樹狀作用範圍的bean，那麼最好的辦法是通過<h:commandLink>使它成爲一個POST請求，而不是通過與?faces-redirect=true參數返回導航結果發出重定向。但畢竟這不是搜索引擎優化，因爲機器人將不會索引POST鏈接。
我畢竟不在乎會議中仍在觀看的視角。如果你打算做一些清理或日誌記錄，我會尋找其他方法，具體取決於具體的功能要求。
在理論有可能通過HTML DOM onbeforeunload事件，但是這是一個非標準的事件和瀏覽器的行爲是不確定的，當你發送活動期間Ajax請求會發生什麼。它有時會到達，但有時也不會。 更新：在練習，由於OmniFaces 2.2在synchronous XHR的幫助下已在OmniFaces @ViewScoped中實現，並且它在主流瀏覽器中運行良好。從版本2.3開始，它甚至在物理上破壞了關聯的JSF服務器側視圖狀態。
我準備了一個小的NetBeans項目，演示何時在不同的導航情況下爲JSF2.2兼容CDI的@ViewScoped bean（javax.faces.view.ViewScoped）發佈垃圾回收（針對Mojarra 2.2.9，Glassfish4，NetBeans8 .0.2，JDK1.7），可用於download here。 此處省略代碼，請參閱下載。
導航案件處理，並將結果通過這一形象概括：
要監視@ViewScoped豆，使用的VisualVM對Glassfish的（或在小型項目中內置對NetBeans Profiler ）並過濾包名「webel.com.jsf」上的採樣器內存堆直方圖類視圖。下圖顯示了一個荒謬的66個實例： webel.com.jsf.Jsf22ViewBean經過對h：link，瀏覽器URL GET和瀏覽器RELOAD GETs的大量試驗後，哪些實例不會被垃圾收集（您可以使用VisualVM Perform GC按鈕）：
通過比較，從所述的index.xhtml（它使用@ViewScoped豆一次簡單的EL可變的讀取導航遠）到done.xhtml（不在使用bean所有）使用h：commandButton和一個操作方法表達式或一個操作字符串導致@ViewScoped bean被釋放以進行垃圾回收（總是有一個從WeldClientProxy引用到@ViewScoped bean的引用，並且當您回到使用h：commandButton，WeldClientProxy從一個可釋放的bean移動到下一個）。
以上回答了這個問題（進一步建立在BalusC的答案上），詳盡地展示了各種導航案例，但它沒有解釋如何處理所產生的「晃來晃去」的@ViewScoped bean，它們不會垃圾收集：我要求問題在這裏：http://stackoverflow.com/questions/30410601/jsf2-2-how-detect-and-remove-unused-viewscoped-beans-that-cant-be-garbage-col –
一個小的更正是爲了。即使你做了重定向，如果你重定向到POST請求的源視圖，JSF也不會銷燬視圖範圍的bean。對於要銷燬的視圖範圍的bean，在處理POST請求後，您將需要完全呈現不同的視圖。 – RajV