※ 引述《easy1 (e :) y)》之铭言： : ※ 引述《adrianshum (Alien)》之铭言： : : 没有什麽异想天开的，我记忆中我有做过类似的东西. : : 当然一般来说不会搞这些麻烦东西 XDD : 嗯 结果你印象中 这样的做法"划算"吗 : 效能有不错吗 (还有毕竟我没写过这种concurent程式..:-( ) : 如果读/写比例不会差太多的时候 我当时做是 C++ 的 XD 不过概念上没有什麽不同 :P 划算嘛... 那还好，因为本身 map 中的物件不算多 （最多也只是几千个），二来因为本身真的要有不少 update, 如果单一个 lock 的话是死定了. 跑起来也 没有明显的 performance 问题. 但我想这要视乎你自己的实际情况来决定了. 但简单来说，物件不是太多，有频繁的读，但写入也 不少的话，每个 entry 一个 lock 的做法该划算的，不然 synchronization 必定会成为 bottleneck : : 不会两次 W lock. : : 一般来说的做法是，要新加入 entry, 才会acquire map 的 W lock. : : (新加入 entry 也不需取新 entry 的 W lock 哪） : : 修改现有的 entry 的话则只取 map read lock, 然後取 entry write lock. : : Alien : 嗯 我也这麽想 : 我现在想法是用 ConcurrentHashmap 搭配 map w/r lock 和 各各 entry 的 r/w lock : (ConcurrentHashmap支援同时更改map结构) : 我的需求大概是 读/写比 = 1.5 ~ 2 , entry 数量四位数.. 但同时读的机会大吗？ 大概有多少 thread 同时读？ 比例有时不大有意思 比如只有一 read thread 一 write thread, 大概每 read 两次就有一次 write, 这种情况不用 RW lock 也无妨。 : 如果简单一点用 HashMap 加只有一个 map w/r lock : (有write 就lock整张map) : 看起来程式比较好写 效能会差很多吗...XD 这真的要看你自己的情况才知道了... 另，有提到会不会有太多 lock object，我以前有想过一个 解决方法但没有实际 implement 过，你可以试试。 造一个 Lock Pool, 假设里面有 30 个 lock 好了，每个加 入 map 的 entry 不是自己有一个独立的 lock, 而是指向 Lock pool 中的某一个 Lock. 换句话就是几个 map entry share 一个 Lock . 虽然这种做法会出现某 entry 的 read 会因为另一 entry 的 write 而被 block, 但至少是取平衡 的方法。 Alien Alien --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 219.77.26.195