从数据库并行反序列化 Json

Question

这是这样的场景：在一个单独的任务中，我从一个数据读取器读取数据，该数据读取器表示一个带有字符串 JSON 的单列结果集。在该任务中，我将 JSON 字符串添加到包装 ConcurrentQueue 的 BlockingCollection。同时在主线程中我 TryTake/dequeue 从集合中提取一个 JSON 字符串，然后将其反序列化后返回。

从数据库读取和反序列化的速度大致相同，因此不会因大的 BlockingCollection 导致过多的内存消耗。

从数据库读取完成后，任务关闭，然后我反序列化所有非反序列化的 JSON 字符串。

问题/想法：

1) TryTake 是否加锁，无法添加？

2) 不要这样做。只需串行执行并返回即可。

using (var q = new BlockingCollection<string>())
{
Task task = null;

try
{
    task = new Task(() =>
    {
        foreach (var json in sourceData)
            q.Add(json);
    });

    task.Start();

    while (!task.IsCompleted)
    {
        string json;
        if (q.TryTake(out json))
            yield return Deserialize<T>(json);
    }

    Task.WaitAll(task);
}
finally 
{
    if (task != null)
    {
        task.Dispose();
    }

    q.CompleteAdding();
}

foreach (var e in q.GetConsumingEnumerable())
    yield return Deserialize<T>(e);
}

Answer 1

问题 1

TryTake 是否加锁，无法添加

会有很短的时间无法执行添加，但这段时间可以忽略不计。来自http://msdn.microsoft.com/en-us/library/dd997305.aspx

一些并发集合类型使用轻量级 SpinLock、SpinWait、SemaphoreSlim 等同步机制， 和 CountdownEvent，它们是 .NET Framework 4 中的新功能。这些 同步类型通常使用短暂的忙旋转 在他们将线程置于真正的等待状态之前。当等待时间 预计很短，旋转的计算量要少得多 比等待更昂贵，这涉及昂贵的内核转换。 对于使用旋转的集合类，这种效率意味着 多个线程可以以非常高的速率添加和删除项目。为了 有关旋转与阻塞的更多信息，请参阅 SpinLock 和 旋转等待。

ConcurrentQueue 和 ConcurrentStack 类不使用锁 一点也不。相反，他们依靠联锁操作来实现 线程安全。

问题 2：

不要这样做。只需串行执行并返回即可。

这似乎是要走的路。与任何优化工作一样 - 做最简单的事情，然后进行测量！如果这里存在瓶颈，请考虑进行优化，但至少您会知道您的“优化”是否真的有帮助，因为有指标可供比较。