當SessionTracker的會話超時檢查執行緒整理出一些已經過期的會話後，那麼就要開始進行會話清理了。會話清理的步驟大致可以分為以下7步。

標記會話狀態為“已關閉”

由於整個會話清理過程需要一段的時間，因此為了保證在此期間不再處理來自該客戶端的新請求，SessionTracker會首先將該會話的isClosing屬性標記為true。這樣，即使在會話清理期間接收到該客戶端的新請求，也無法繼續處理了。

發起“會話關閉”請求

為了使對該會話的關閉操作在整個服務端叢集中都生效，ZooKeeper使用了提交“會話關閉”請求的方式，並立即交付給PrepRequestProcessor處理器進行處理。

收集需要清理的臨時節點

在ZooKeeper中，一旦某個會話失效後，那麼和該會話相關的臨時（EPHEMERAL）節點都需要被一併清除掉。因此，在清理臨時節點之前，首先需要將伺服器上所有和該會話相關的臨時節點都整理出來。

在ZooKeeper的記憶體資料庫中，為每個會話都單獨儲存了一份由該會話維護的所有臨時節點集合，因此在會話清理階段，只需要根據當前即將關閉的會話的sessionID從記憶體資料庫中獲取到這份臨時節點列表即可。

但是，在實際應用場景中，情況並沒有那麼簡單，有如下的細節需要處理：在ZooKeeper處理會話關閉請求之前，正好有以下兩類請求到達了服務端並正在處理中。

• 節點刪除請求，刪除的目標節點正好是上述臨時節點中的一個。
• 臨時節點建立請求，建立的目標節點正好是上述臨時節點中的一個。

對於這兩類請求，其共同點都是事務處理尚未完成，因此還沒有應用到記憶體資料庫中，所以上述獲取到的臨時節點列表在遇上這兩類事務請求的時候，會存在不一致的情況。

假定我們當前獲取的臨時節點列表是ephemerals，那麼針對第一類請求，我們需要將所有這些請求對應的資料節點路徑從ephemerals中移除以避免重複刪除。針對第二類請求，我們需要將所有這些請求對應的資料節點路徑新增到ephemerals中去，以刪除這些即將會被建立但是尚未儲存到記憶體資料庫中去的臨時節點。

新增“節點刪除”事務變更

完成該會話相關的臨時節點收集後，ZooKeeper會逐個將這些臨時節點轉換成“節點刪除”請求，並放入事務變更佇列outstandingChanges中去。

刪除臨時節點

在上面的步驟中，我們已經收集了所有需要刪除的臨時節點，並建立了對應的“節點刪除”請求，FinalRequestProcessor處理器會觸發記憶體資料庫，刪除該會話對應的所有臨時節點。

移除會話

完成節點刪除後，需要將會話從SessionTracker中移除。主要就是從上面提到的三個資料結構（sessionById、sessionsWithTimeout和sessionSets）中將該會話移除掉。

關閉NIOServerCnxn

最後，從NIOServerCnxnFactory找到該會話對應的NIOServerCnxn，將其關閉。