推 jej: 你的Map放在全域變數 要thread safe就有困難 12/17 09:55
→ jej: 如果不能放在block裡面 一定要放全域 12/17 09:56
→ jej: 可以考慮用concurrent package下的lock 12/17 09:56
→ jej: 或是使用 synchronized鎖定這個Map 12/17 09:56
→ jej: 但如果你有效能考慮 還是建議你重構 看看能不能用singleton 12/17 09:56
→ jej: 把map重構在block裡 12/17 09:56
→ jerrychen26: 感謝回答,不過我的問題點比較在於當用synchronized( 12/17 10:05
→ jerrychen26: map.get(key)) 的block期間,可以保證被get出來的這 12/17 10:05
→ jerrychen26: 個list 能達成執行緒安全嗎? 12/17 10:05
推 jej: 你這樣是鎖的東西是什麼就未知了 而且也不一定是單一物件 12/17 11:12
→ jej: 多執行緒還是gg吧 所以才說要不要鎖map 12/17 11:12
→ ssccg: ConcurrentHashMap.compute 12/17 13:00
→ ssccg: (key, (k, list) -> { list.add(value); return list }); 12/17 13:02
→ ssccg: 如果需要考慮list為空,就再加個檢查和new 12/17 13:03
→ ssccg: 不過compute只會擋update類型的作業,你要達到類似DB交易 12/17 13:16
→ ssccg: (update中也block其他get)的話,就是get也改用compute 12/17 13:16
→ ssccg: 你的3 4作法其實效果一樣,IntelliJ的警告只是個提醒,真正 12/17 14:44
→ ssccg: 的問題在於你synchonized list的期間,如果別的thread做了 12/17 14:45
→ ssccg: Map.put(key, ...),你的list是安全的,但是map.get(key)已 12/17 14:46
→ ssccg: 不再是你的list而是別的東西,所以一樓才建議鎖map 12/17 14:47
→ ssccg: 都用compute可以解決這問題 12/17 14:49
→ ssccg: 更正,4的作法有個更糟的點是兩個map.get(key)間還有空窗, 12/17 14:54
→ ssccg: 這中間map.put(key,...)的話,呼叫add的list跟上鎖的不同 12/17 14:55
→ jerrychen26: 理解了,感謝解答 12/17 15:43
→ darkk6: 做法跟你的 map/list 操作有關,看你是否預期他們會被改變 12/22 01:37
→ darkk6: 會/不會,都有不同適合的寫法 12/22 01:37
→ flowwinds: 把key當mutex? 01/08 21:46