我們?cè)谖覀兊亩嗑€(xiàn)程應(yīng)用程序中使用下面ConcurrentHashMap作為緩存。private static Map<String, TransactionPriceItemDetailSummaryVO> pritmSummaryMap = new ConcurrentHashMap<String, TransactionPriceItemDetailSummaryVO>();我們正在創(chuàng)建130 個(gè)線(xiàn)程來(lái)訪(fǎng)問(wèn)和更新此地圖。最終地圖大小約為1 億（對(duì)象）。我在網(wǎng)上讀到我們需要指定參數(shù)ConcurrentHasMap來(lái)提高它的性能。誰(shuí)能建議我們?nèi)绾螢槲覀兊陌咐?jì)算參數(shù)？clear()另外，調(diào)用此地圖以釋放內(nèi)存是最佳做法嗎？
3 回答
慕斯709654
TA貢獻(xiàn)1840條經(jīng)驗(yàn) 獲得超5個(gè)贊
來(lái)自java doc：理想情況下，您應(yīng)該選擇一個(gè)值來(lái)容納盡可能多的線(xiàn)程來(lái)同時(shí)修改表。既然你說(shuō)
... 130 個(gè)線(xiàn)程正在訪(fǎng)問(wèn)和更新此地圖
那么你應(yīng)該使用
new ConcurrentHashMap<String, TransactionPriceItemDetailSummaryVO>(130)
正如@Bohemian 所說(shuō)，設(shè)置一些更大的值以避免調(diào)整大小。僅當(dāng)您不需要內(nèi)容時(shí)才調(diào)用 clear。
holdtom
TA貢獻(xiàn)1805條經(jīng)驗(yàn) 獲得超10個(gè)贊
您可以使用以下構(gòu)造函數(shù)配置您的地圖：
ConcurrentHashMap<K,V>(initialCapacity, loadFactor, concurrencyLevel).
initialCapacity：雖然您提到您將插入 100M 個(gè)對(duì)象，但您是否要將它們保留在地圖中？還是就像添加和刪除對(duì)象一樣？如果您要保留所有這些而不是刪除它們，那么按照 Bohemian 的建議保留此值是有意義110_000_000的，否則，您應(yīng)該在任何給定時(shí)間點(diǎn)將其保留為地圖的 appx 平均大小。
loadFactor: 較高的負(fù)載因子值會(huì)減少空間開(kāi)銷(xiāo)，但會(huì)增加查找成本。這意味著它對(duì)get并且put因?yàn)檫@兩種方法都在內(nèi)部進(jìn)行查找具有重大影響。默認(rèn)情況下，它0.75通常被認(rèn)為是空間利用率和查找時(shí)間之間的良好折衷。
concurrencyLevel：估計(jì)的并發(fā)更新線(xiàn)程數(shù)。在這種情況下，您提到的數(shù)字是130
clear()通過(guò)分析您何時(shí)調(diào)用刪除所有元素，可以進(jìn)一步深入挖掘上述值。
慕田峪9158850
TA貢獻(xiàn)1794條經(jīng)驗(yàn) 獲得超8個(gè)贊
有了這么多的條目和線(xiàn)程，您可以通過(guò)構(gòu)造函數(shù)告訴它預(yù)期的大小來(lái)幫助實(shí)現(xiàn)更好地執(zhí)行：
new ConcurrentHashMap<>(110_000_000, 10, 130);
嘗試不同的數(shù)字以找出有效的方法。
請(qǐng)注意，使用這么多項(xiàng)目，您將獲得很高的哈希沖突率?？紤]使用基于不同鍵的嵌套映射，以便每個(gè)映射的條目更少，例如 1M 以下。
添加回答
舉報(bào)
0/150
提交
取消