ConcurrentQueue的ArgumentNullException怎么捕获？-C#.Net教程-PHP中文网

concurrentqueue仅在构造函数传入null的ienumerable<t>参数时会抛出argumentnullexception；2. enqueue或trydequeue等操作不会因添加或移除null元素而抛出该异常，因为对于引用类型null是合法值；3. 值类型无法直接enqueue(null)，会在编译时报错；4. 其他可能异常包括outofmemoryexception（内存不足时）和operationcanceledexception（结合cancellationtoken使用时），但非常罕见；5. 编写健壮代码应优先校验构造参数是否为null，使用try方法处理操作结果，业务层检查null项，结合blockingcollection实现阻塞或限流，并做好日志记录与监控。因此，concurrentqueue抛出argumentnullexception的唯一常见场景是构造时传入null集合，其余操作应通过返回值而非异常控制流程。

ConcurrentQueue的ArgumentNullException怎么捕获？

在处理

ConcurrentQueue

登录后复制

时，

ArgumentNullException

登录后复制

通常发生在队列的构造阶段，当你尝试用一个

null

登录后复制

集合来初始化它时。如果你在后续操作如

Enqueue

登录后复制

或

TryAdd

登录后复制

时遇到这类异常，那往往不是

ConcurrentQueue

登录后复制

本身抛出的，而是你尝试放入的元素本身就是

null

登录后复制

，而你的代码或泛型类型约束不允许

null

登录后复制

。捕获它，最直接的方式就是围绕可能引发异常的代码块使用

try-catch

登录后复制

。

解决方案

要捕获

ConcurrentQueue

登录后复制

在构造时可能抛出的

ArgumentNullException

登录后复制

，你可以这样做：

using System;
using System.Collections.Concurrent;
using System.Collections.Generic;

public class QueueExample
{
    public static void Main(string[] args)
    {
        IEnumerable<string> initialItems = null; // 模拟一个null集合

        try
        {
            // 尝试用一个null集合初始化ConcurrentQueue
            ConcurrentQueue<string> myQueue = new ConcurrentQueue<string>(initialItems);
            Console.WriteLine("队列初始化成功 (这通常不会发生，如果initialItems是null)。");
            myQueue.Enqueue("Item A");
            Console.WriteLine("已添加 Item A。");
        }
        catch (ArgumentNullException ex)
        {
            Console.WriteLine($"捕获到 ArgumentNullException: {ex.Message}");
            Console.WriteLine("这通常是因为尝试用一个null集合初始化ConcurrentQueue。");
            // 可以在这里进行错误日志记录，或者采取其他恢复措施
        }
        catch (Exception ex)
        {
            // 捕获其他可能的异常
            Console.WriteLine($"捕获到未知异常: {ex.GetType().Name} - {ex.Message}");
        }

        // 另一个常见的误解：Enqueue(null)对于引用类型不会抛出ArgumentNullException
        ConcurrentQueue<string> anotherQueue = new ConcurrentQueue<string>();
        string nullItem = null;
        try
        {
            anotherQueue.Enqueue(nullItem); // 对于string类型，null是合法的值
            Console.WriteLine("成功将null添加到队列 (对于引用类型是允许的)。");
            if (anotherQueue.TryDequeue(out string retrievedItem))
            {
                Console.WriteLine($"出队项: {(retrievedItem == null ? "null" : retrievedItem)}");
            }
        }
        catch (ArgumentNullException ex)
        {
            Console.WriteLine($"捕获到 ArgumentNullException (不应该发生): {ex.Message}");
        }
        catch (Exception ex)
        {
            Console.WriteLine($"捕获到未知异常: {ex.GetType().Name} - {ex.Message}");
        }
    }
}

登录后复制

ConcurrentQueue在什么情况下会抛出ArgumentNullException？

说实话，

ConcurrentQueue<T>

登录后复制

抛出

ArgumentNullException

登录后复制

的场景是比较有限的，而且通常不是在使用

Enqueue

登录后复制

或

TryDequeue

登录后复制

这些核心操作时。我个人在实际开发中遇到的大多数

ArgumentNullException

登录后复制

，都是因为对API的误解或者参数校验不严谨造成的。

最典型的、也是几乎唯一的会由

ConcurrentQueue

登录后复制

自身直接抛出

ArgumentNullException

登录后复制

的情况，就是当你尝试使用它的构造函数，并且传入的

IEnumerable<T>

登录后复制

集合参数是

null

登录后复制

的时候。比如：

IEnumerable<MyObject> myCollection = null;
ConcurrentQueue<MyObject> queue = new ConcurrentQueue<MyObject>(myCollection); // 这里会抛出ArgumentNullException

登录后复制

这个异常的抛出，是因为

ConcurrentQueue

登录后复制

的构造函数需要一个非空的集合来初始化内部状态，即使这个集合是空的（

new List<MyObject>()

登录后复制

），那也是一个有效的、非

null

登录后复制

的集合。

至于向

ConcurrentQueue

登录后复制

中添加

null

登录后复制

元素，比如

myQueue.Enqueue(null);

登录后复制

，这取决于泛型参数

登录后复制

的类型。如果

登录后复制

是一个引用类型（如

string

登录后复制

object

登录后复制

MyClass

登录后复制

），那么

null

登录后复制

是一个完全合法的元素值，

ConcurrentQueue

登录后复制

会毫无问题地接受它。它不会因此抛出

ArgumentNullException

登录后复制

。就好比一个箱子，你可以放一个空的包裹进去，箱子本身不会抱怨。

如果

登录后复制

是一个值类型（如

int

登录后复制

struct

登录后复制

），那么你根本无法直接

Enqueue(null)

登录后复制

，因为值类型不能是

null

登录后复制

（除非它是

Nullable<T>

登录后复制

类型，比如

int?

登录后复制

）。如果你尝试将一个

null

登录后复制

赋给一个非

Nullable

登录后复制

的值类型变量，那会在编译时就报错。所以，对于值类型，

Enqueue(null)

登录后复制

这个操作从一开始就不存在。

所以，核心在于：

ArgumentNullException

登录后复制

通常是关于参数本身是否合法，而不是参数所代表的值是否为空。对于

ConcurrentQueue

登录后复制

，它的构造函数需要一个有效的（非

null

登录后复制

）

IEnumerable<T>

登录后复制

参数。

除了ArgumentNullException，ConcurrentQueue还可能抛出哪些异常？

ConcurrentQueue

登录后复制

的设计理念就是高度并发和健壮，所以它本身直接抛出的异常类型并不多，远比

ArgumentNullException

登录后复制

更少见，或者说，它们通常与更高级的并发控制或系统资源有关。

```
OperationCanceledException
```
登录后复制
: 这个异常通常不会由
```
ConcurrentQueue
```
登录后复制
直接抛出，而是当你结合
```
CancellationToken
```
登录后复制
使用某些方法时（例如，如果你在自定义的消费者循环中，通过
```
CancellationToken
```
登录后复制
来取消一个阻塞的等待操作），或者在一些高级的并发模式中。
```
ConcurrentQueue
```
登录后复制
自身的方法如
```
TryDequeue
```
登录后复制
或
```
TryAdd
```
登录后复制
并没有直接接受
```
CancellationToken
```
登录后复制
的重载，所以这个更多是你的代码逻辑层面的异常处理。

千面视频动捕
千面视频动捕是一个AI视频动捕解决方案，专注于将视频中的人体关节二维信息转化为三维模型动作。

27

查看详情
```
OutOfMemoryException
```
登录后复制
: 任何数据结构在内存不足时都可能抛出这个异常。
```
ConcurrentQueue
```
登录后复制
当然也不例外。如果你持续地向队列中添加大量元素，而不进行消费，最终可能会耗尽系统内存。这通常发生在非常极端或设计不当的场景下，比如一个生产者速度远远超过消费者，导致队列无限膨胀。
```
InvalidOperationException
```
登录后复制
: 这种情况在
```
ConcurrentQueue
```
登录后复制
中比较罕见，因为它在内部处理了并发访问。但如果你尝试在对队列进行迭代（比如使用
```
foreach
```
登录后复制
）的同时，从另一个线程修改队列（添加或移除元素），理论上可能会遇到意想不到的行为，尽管
```
ConcurrentQueue
```
登录后复制
的迭代器是"快照"式的，通常不会抛出
```
InvalidOperationException
```
登录后复制
。然而，如果你在自定义的并发逻辑中，错误地假设了某些状态，就可能间接导致
```
InvalidOperationException
```
登录后复制
，但这已经脱离了
```
ConcurrentQueue
```
登录后复制
本身的范畴。

总的来说，

ConcurrentQueue

登录后复制

是一个非常可靠的并发集合。它被设计用来在多线程环境下安全地工作，并且尽量避免抛出异常，而是通过返回布尔值（如

TryEnqueue

登录后复制

TryDequeue

登录后复制

）来指示操作成功与否，这是一种更优雅的错误处理方式。所以，大部分你遇到的问题，更可能是业务逻辑层面的错误，而不是

ConcurrentQueue

登录后复制

本身的缺陷。

如何编写更健壮的ConcurrentQueue使用代码？

编写健壮的

ConcurrentQueue

登录后复制

代码，不仅仅是捕获异常那么简单，更多的是一种防御性编程的思维，以及对并发模式的深刻理解。我个人在写这类代码时，会特别关注以下几个点：

参数校验先行：在将任何集合传递给

ConcurrentQueue

登录后复制

的构造函数之前，始终检查它是否为

null

登录后复制

。如果外部传入的集合可能是

null

登录后复制

，你最好自己创建一个空的

ConcurrentQueue

登录后复制

实例，而不是让构造函数抛出异常。

IEnumerable<MyItem> initialData = GetInitialDataFromSomewhere(); // 可能是null
ConcurrentQueue<MyItem> queue;
if (initialData == null)
{
    queue = new ConcurrentQueue<MyItem>(); // 传入null，不如直接初始化一个空的
    Console.WriteLine("初始数据为null，创建了一个空队列。");
}
else
{
    queue = new ConcurrentQueue<MyItem>(initialData);
}

登录后复制

*利用`Try

方法**：

登录后复制

ConcurrentQueue

的

登录后复制

TryEnqueue

、

登录后复制

TryDequeue

和

登录后复制

TryPeek

方法是其健壮性的核心。它们不会在操作失败时抛出异常，而是返回一个布尔值指示操作是否成功。这比

登录后复制

try-catch`更高效，也更符合其设计意图。

// 生产者
public void Produce(ConcurrentQueue<MyItem> queue, MyItem item)
{
    if (item == null) // 如果你的业务逻辑不允许null项，在这里进行检查
    {
        Console.WriteLine("尝试添加null项，已拒绝。");
        return;
    }
    queue.Enqueue(item); // Enqueue总是成功的，除非OOM
    Console.WriteLine($"已生产: {item.Id}");
}

// 消费者
public void Consume(ConcurrentQueue<MyItem> queue)
{
    if (queue.TryDequeue(out MyItem item)) // 尝试出队，如果队列为空则返回false
    {
        // 处理item
        Console.WriteLine($"已消费: {item.Id}");
    }
    else
    {
        // 队列为空，可以等待或执行其他逻辑
        Console.WriteLine("队列为空，无项可消费。");
    }
}

登录后复制

考虑
```
null
```
登录后复制
项的业务含义：虽然
```
ConcurrentQueue<T>
```
登录后复制
允许引用类型为
```
null
```
登录后复制
的项，但你的业务逻辑可能不允许。在这种情况下，应该在
```
Enqueue
```
登录后复制
之前显式地检查
```
null
```
登录后复制
，而不是依赖
```
ConcurrentQueue
```
登录后复制
抛出异常。
```
MyItem newItem = GetNextItem(); // 可能会返回null
if (newItem != null) // 业务逻辑层面的null检查
{
    myQueue.Enqueue(newItem);
}
else
{
    Console.WriteLine("尝试添加的项为null，已跳过。");
}
```
登录后复制
优雅地处理队列空/满：对于生产者-消费者模式，队列空（消费者等待）和队列满（生产者等待）是很常见的场景。
```
ConcurrentQueue
```
登录后复制
本身没有容量限制（除了内存），也没有阻塞方法。如果需要阻塞行为或容量限制，通常会结合
```
BlockingCollection<T>
```
登录后复制
（它内部可以使用
```
ConcurrentQueue
```
登录后复制
作为存储），或者自己实现等待/通知机制（如使用
```
SemaphoreSlim
```
登录后复制
或
```
ManualResetEventSlim
```
登录后复制
）。
日志记录和监控：在生产环境中，任何异常都应该被记录下来。即使是
```
ArgumentNullException
```
登录后复制
，也说明你的代码在某种情况下收到了不合法的输入。详细的日志可以帮助你追踪问题的根源。同时，监控队列的长度，可以帮助你发现潜在的生产者-消费者失衡问题。