.NET Core容器中Azure Blob API的GetPropertiesAsync()挂起问题

• 核心原因
  这种只挂起不抛超时异常的情况，主要和两个点有关：

  1. 线程池资源耗尽：WSL的Linux容器环境中，.NET线程池的可用线程可能因为系统资源限制（比如文件句柄不足、未释放的网络连接）被耗尽，导致GetPropertiesAsync()的异步操作无法获得调度线程，既无法完成也不会触发超时逻辑。
  2. 早期SDK的连接池Bug：你使用的Azure.Storage.Blobs V12.6属于较早版本，在Linux环境下存在HTTP连接池的问题——当WSL网络转发层把连接挂起但未标记为失效时，客户端会一直等待该连接的响应，不会触发内置的超时检测，因为客户端认为连接仍处于存活状态。

• 重启解决问题的逻辑
  重启会清空WSL的网络连接池、重置.NET线程池的状态，同时释放所有被占用的系统资源（比如残留的半开连接、耗尽的文件句柄），让异步操作的调度和网络通信恢复正常。

• 后续避免该问题的建议

  • 升级Azure.Storage.Blobs到最新稳定版本：后续版本修复了大量Linux环境下的连接池和线程调度问题，能从根源减少这类无响应情况。
  • 显式配置超时参数：在初始化BlobClient时，通过BlobClientOptions手动设置Retry.TryTimeout和Retry.MaxRetries，强制让超时逻辑生效，即使连接被挂起也能触发重试或抛出超时异常。示例代码：

    var options = new BlobClientOptions
    {
        Retry =
        {
            TryTimeout = TimeSpan.FromSeconds(30),
            MaxRetries = 3
        }
    };
    var blobClient = new BlobClient(connectionString, containerName, blobName, options);
    

  • 检查容器资源限制：在Linux容器中执行ulimit -n查看文件句柄上限，若数值较低（比如默认的1024），可以调高到65535，避免因为文件句柄耗尽导致无法创建新的网络连接。

内容的提问来源于stack exchange，提问作者Steven.Xi