collection.immutable.Map[ K, SoftReference[ V ]] 超过 google 的 MapMaker？
假设一个潜在的多线程环境。我想将地图与（值）缓存一起使用。为什么我更喜欢其中一个
collection.immutable.Map.empty[ K, SoftReference[ V ]]
new com.google.common.collect.MapMaker.softValues.makeMap[ K, V ]
而不是另一个？该地图将存储在 STM 引用中，因此不可变将是直接且良好的。此外，K 很可能是 Long，因此我可以使用 collection.immutable.LongMap。
在这里使用谷歌收藏有什么好处？性能和空间方面？
Assume a potentially multi-threaded environment. I want to use a map along with (value) caching. Why would I prefer one of
collection.immutable.Map.empty[ K, SoftReference[ V ]]
new com.google.common.collect.MapMaker.softValues.makeMap[ K, V ]
over the other? The map is going to be stored in an STM ref, so immutable would be straight forward and fine. Furthermore, K is most likely going to be Long, so I could use collection.immutable.LongMap.
What would be the advantage of using google collections here? Performance and space wise?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
在我看来，Google 方法的主要优点是生成的 API 更干净，即为您插入 SoftReference 并对其进行 null 检查，而不需要您管理它们。但保证不变性和原生 Scala API 是另一列中的标记。
我倾向于尝试编写一个 mixin（类似于我们在标准库中已有的 MultiMap，不幸的是它是可变的）。
IMO the major advantage of Google's approach is the resulting API is cleaner, i.e. the
SoftReferences are inserted and null-checked for you, rather than your needing to manage them. But the guaranteed immutability and native Scala API are marks in the other column.I'd be inclined to experiment with writing a mixin (similar to the
MultiMapwe already have in the standard library, which is unfortunately mutable).