我想强调问题中的"3.5"。我知道这些东西在4.0中发生了很多变化，但我还没有机会访问这些东西。
我有一个TCP客户端类，它从另一个应用程序获取数据并将其放入队列中，UI线程会定期调用一个函数从中获取数据。目前，我在从两侧访问队列时会锁定队列，当网络上传入太多数据时，我会遇到问题。
我想我可以实现某种循环缓冲区来实现这一点，但我假设这已经可以使用一些.NET类来实现了。
带锁的Queue似乎是一种合理的方法，只要您只持有对Queue方法（编写器端）或Dequeue方法（读取器端）的调用的锁，我就不会想到性能问题。你确定锁是问题所在吗？
请注意，@Jon B的回答中建议的ReaderWriterLock并没有真正的帮助，因为您只有一个读取器，而且在任何情况下，您都需要一个写锁来调用Dequeue。
ReaderWriterLock可能有帮助的唯一情况是，如果有多个读取器线程调用Peek方法，那么它们只需要一个读锁。
如果队列是瓶颈，请尝试以下方法。为每个使用者提供一个负载均衡器和一个队列。负载均衡器将传入的请求放入消费者的队列中；这是根据哪个消费者队列最空闲（比如说最小的队列大小）来完成的。
我在这里对生产商和消费者的速度和数量做了很多假设，但这是一个基本的想法。您的新瓶颈将是负载均衡器。正如您所看到的，当消费者需要完成计算密集型任务时，这是有效的。
您也可以尝试ReaderWriterLockSlim。该链接还包含如何使用它的示例。它比ReaderWriterLock:更可取
.NET Framework有两个读写器锁，ReaderWriterLockSlim和ReaderWriterLock。建议将ReaderWriterLockSlim用于所有新发展ReaderWriterLockSlim类似于ReaderWriterAlock，但是它简化了递归、升级和降级锁定状态。ReaderWriterLockSlim避免了潜在的僵局。此外ReaderWriterLockSlim明显优于ReaderWriterAlock。
然而，正如@Joe正确指出的那样，您需要为pop和push操作设置写入程序锁定。