我有一个队列，入队操作将由一个线程执行，而出队操作将由另一个线程执行。不用说，我必须为它实现一些线程安全。
我首先尝试在每个入队/出队之前对队列使用锁定，因为它可以更好地控制锁定机制。它运作良好，但我好奇的头脑让我进行了更多测试。
然后我尝试使用 Queue.Synchronized 包装器保持其他所有内容相同。现在，我不确定它是否属实，但这种方法的性能似乎确实有点快。
您是否认为，两者之间的性能实际上存在一些差异，或者我只是在这里想象一些事情..？ :)
【问题讨论】：
标签： c# multithreading performance .net-3.5 queue
当请求Queue.Synchonized 时，你会得到一个SynchronizedQueue 作为回报，它在内部队列上对Enqueue 和Dequeue 的调用很少使用lock。因此，性能应该与使用Queue 并使用自己的lock 管理锁定Enqueue 和Dequeue 相同。
你确实在想象事物——它们应该是一样的。
更新
事实上，当使用SynchronizedQueue 时，您正在添加一个间接层，因为您必须通过包装器方法才能到达它所管理的内部队列。如果有的话，这应该会大大减慢速度，因为堆栈上有一个额外的帧需要为每次调用进行管理。上帝知道内联是否会取消这一点。无论如何 - 它是最小的。
更新 2
我现在已经对此进行了基准测试，并且正如我之前的更新中所预测的那样：
“Queue.Synchronized”比“Queue+lock”慢
我进行了单线程测试，因为它们都使用相同的锁定技术（即lock），因此以“直线”测试纯开销似乎是合理的。
我的基准测试为 Release 构建产生了以下结果：
Iterations :10,000,000
Queue+Lock :539.14ms
Queue+Lock :540.55ms
Queue+Lock :539.46ms
Queue+Lock :540.46ms
Queue+Lock :539.75ms
SynchonizedQueue:578.67ms
SynchonizedQueue:585.04ms
SynchonizedQueue:580.22ms
SynchonizedQueue:578.35ms
SynchonizedQueue:578.57ms
使用以下代码：
private readonly object _syncObj = new object();
[Test]
public object measure_queue_locking_performance()
{
const int TestIterations = 5;
const int Iterations = (10 * 1000 * 1000);
Action<string, Action> time = (name, test) =>
{
for (int i = 0; i < TestIterations; i++)
{
TimeSpan elapsed = TimeTest(test, Iterations);
Console.WriteLine("{0}:{1:F2}ms", name, elapsed.TotalMilliseconds);
}
};
object itemOut, itemIn = new object();
Queue queue = new Queue();
Queue syncQueue = Queue.Synchronized(queue);
Action test1 = () =>
{
lock (_syncObj) queue.Enqueue(itemIn);
lock (_syncObj) itemOut = queue.Dequeue();
};
Action test2 = () =>
{
syncQueue.Enqueue(itemIn);
itemOut = syncQueue.Dequeue();
};
Console.WriteLine("Iterations:{0:0,0}\r\n", Iterations);
time("Queue+Lock", test1);
time("SynchonizedQueue", test2);
return itemOut;
}
[SuppressMessage("Microsoft.Reliability", "CA2001:AvoidCallingProblematicMethods", MessageId = "System.GC.Collect")]
private static TimeSpan TimeTest(Action action, int iterations)
{
Action gc = () =>
{
GC.Collect();
GC.WaitForFullGCComplete();
};
Action empty = () => { };
Stopwatch stopwatch1 = Stopwatch.StartNew();
for (int j = 0; j < iterations; j++)
{
empty();
}
TimeSpan loopElapsed = stopwatch1.Elapsed;
gc();
action(); //JIT
action(); //Optimize
Stopwatch stopwatch2 = Stopwatch.StartNew();
for (int j = 0; j < iterations; j++) action();
gc();
TimeSpan testElapsed = stopwatch2.Elapsed;
return (testElapsed - loopElapsed);
}
【讨论】：
Enqueue 和 Dequeue 调用周围使用了最低限度的锁定，但我明白你的意思。我在回答中已经澄清了一点。
我们无法为您回答这个问题。只有您自己可以通过获取分析器并根据您的应用程序中的真实数据测试两种场景（Queue.Synchronized 与 Lock）来自己回答这个问题。它甚至可能不是您的应用程序的瓶颈。
也就是说，您可能应该只使用ConcurrentQueue。
【讨论】：
ConcurrentQueue<T> 的后向端口。
ConcurrentQueue<T> 实际上通常更快吗？我已经看过几次该建议，但没有实际的性能数据。有数字吗？
ConcurrentQueue<T> 一样快，或者它是否比由 lock 语句保护的普通 Queue<T> 更快？在前一种情况下，我不知道。在后一种情况下，它取决于争用的级别（几乎没有争用，带锁的Queue<T> 更好；随着潜在争用的增加，并发版本越来越领先）。如果你愿意，我可能会在某个地方挖掘出一些数字。
System.Threading.Tasks 命名空间。
【讨论】：