我有這種場景,我從數千個來源接收事件。每個來源都發送有關其當前狀態的信息。雖然我想處理所有事件,但首先處理每個源的最新事件更爲重要,以便當前視圖處於最新狀態。所以我想使用ConcurrentHashMap
,每個源的標識符作爲關鍵字,並且使用LIFO隊列(堆棧)作爲值。然後,我將遍歷Map
的鍵,並從每個源的堆棧中彈出一個項目。從多個生產者密鑰公平排隊隊列
我擔心的是,當我遍歷鍵並從每個鍵的隊列中取出項目時,生產者可能會在隊列中發佈新事件,從而潛在地創建併發問題。生產者也可以在地圖上添加新的鍵,並且遍歷Map
的entrySet
似乎是微弱一致的。這不是一個大問題,因爲新項目將在後續迭代中處理。理想情況下,我也可以在entrySet
的流上使用一些並行處理來加速此過程。
我想知道是否有一個更清潔的方法。事實上,我可以使用LIFO BlockingDequeue
並且首先處理最新的事件,但是這種方法的問題在於有一個來源可能發送比其他來源更多的事件的風險,因此可能比其他來源處理更多的事件。
有沒有其他的數據結構,我可以看看提供這種行爲?基本上我正在尋找的是一種優先處理來自每個來源的事件的方式,同時給消費者處理每個來源的公平機會。
這很有趣。然而,問題是我們需要能夠將新事件添加到堆棧(LIFO隊列),因爲它們是針對特定源進行的,這意味着我們需要在隊列中找到相應的堆棧。我想我可以通過額外的'ConcurrentHashMap'將源的鍵映射到源的LIFO隊列來解決這個問題。 –
jbx
是的,如果源不知道把事件放在哪裏,那麼HashMap應該這樣做。 – Vampire
是的,所以我期望構建的數據結構看起來像一個外部的隊列,只是添加和刪除,但內部它正在做相應優先級的邏輯。我會嘗試將你的建議與hashmap結合起來。 – jbx