【问题标题】:Collection with fastest (concurrent) add operation具有最快(并发)添加操作的集合
【发布时间】:2018-10-22 00:31:36
【问题描述】:

我正在寻找具有最有效的“添加项目”并发操作的集合。 Scala 或 Java 都不错。

我通常:

  • 插入 100.000 个条目,一次一个
  • 不在乎订单
  • 仅在没有追加时读取和清除集合。所以不重要

此外,它应该与多线程一起工作(因此存在并发约束)。但是我需要它在没有并发的情况下最有效:并发安全的设计在没有并发访问的情况下不应该有太大的影响。

我使用这个集合来记录性能测量。这就是为什么不偏向过多的实际性能应该是最有效的。但是,由于集合大小可能很大并且事先不知道,它应该有效地应对大小增加。

那么最好使用哪个集合?

我目前使用mutable.ListBufferbuffer.synchronized{ ... } 围绕追加(和清除)操作。我尝试使用具有类似synchronized{ ... } 块的var buf: List (scala),但它严重影响了测量结果。

【问题讨论】:

  • "插入 100.000 个条目,一次一个","它应该与多线程一起工作"。嗯,是哪一个?
  • 您是否考虑过异步运行add 操作?不管最终收集还是实际添加是否同步?
  • ConcurrentLinkedQueue 看起来不错
  • @Michael 我的意思是两件事:(1)典型的最大大小是 100.000 个条目; (2) 唯一的关键操作是“添加一项”
  • 项数无关。您是同时添加还是顺序添加?

标签: java scala collections concurrency


【解决方案1】:

我会说ConcurrentLinkedQueue。这是使用 CAS 的 O(1) 插入。因此,在中等负载下,您可能不会有更快的插入。如果您的负载非常高,您可能需要考虑LinkedBlockingQueue

既然你说它很可能是单线程的,那么使用 CLQ 和 CAS 将是你的最佳选择。

【讨论】:

  • 就我而言,我实际上并没有看到几个选择之间有太大区别:LBQ 似乎比 CLQ 慢一点,但没什么特别值得注意的。但这些成本与同步 ListBuffer 相似。如果使用合适的添加方法(即::),我什至会得到与同步列表类似的成本。但是对于 List,我对锁定 var 没有信心。
  • 是的,LBQ 在正常负载下会比 CLQ 稍微慢一些。出于所有实际目的,LBQ 应等于添加解决方案时的synchronized。如果您确实使用队列 put/take 功能(我知道您只是放入),则 LBQ 或 CLQ 获胜的地方。
猜你喜欢
  • 1970-01-01
  • 2017-02-17
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多