将控制器方法改为异步是否有收益？当前实现是否合理？

我编写了以下两个ASP.NET控制器方法，分别为同步版本与异步版本。最初我未添加await，而是将逻辑放入Task.Run()中。请问将该方法改为异步是否能带来收益？当前的异步实现方式是否规范？

同步版本 #

[HttpGet("authsignature")]
public IActionResult GetSignSignature([FromQuery] string folder) {
  
  DateTime foo = DateTime.Now;
  long timeStamp = ((DateTimeOffset)foo).ToUnixTimeSeconds();
  var p = new Dictionary<string, object>();

  p.Add("folder", folder); 
  p.Add("timestamp", timeStamp);


  var signature = _cloudinary.Api.SignParameters(p);

  if (string.IsNullOrEmpty(signature)) {
    return BadRequest(new ApiResponse(400));
  }

  return Ok(new {
    cloudUploadUrl = _config.GetSection("CloudinarySettings:CloudUploadUrl").Value,
      cloudName = _cloudinaryConfig.Value.CloudName,
      cloudApiKey = _cloudinaryConfig.Value.ApiKey,
      cloudSignature = signature,
      cloudTimeStamp = timeStamp
  });

}

异步版本 #

[HttpGet("authsignature")]
public async Task<IActionResult> GetSignSignature([FromQuery] string folder) {
  
  DateTime foo = DateTime.Now;
  long timeStamp = ((DateTimeOffset)foo).ToUnixTimeSeconds();
  var p = new Dictionary<string, object>();

  p.Add("folder", folder); 
  p.Add("timestamp", timeStamp);


  var signature = await Task.Run(() => JsonConvert.SerializeObject(_cloudinary.Api.SignParameters(p)));

  if (string.IsNullOrEmpty(signature)) {
    return BadRequest(new ApiResponse(400));
  }

  return Ok(new {
    cloudUploadUrl = _config.GetSection("CloudinarySettings:CloudUploadUrl").Value,
      cloudName = _cloudinaryConfig.Value.CloudName,
      cloudApiKey = _cloudinaryConfig.Value.ApiKey,
      cloudSignature = signature,
      cloudTimeStamp = timeStamp
  });

}

1. 这种异步改法没有收益，反而可能拖慢性能 #

你当前的异步实现是用Task.Run把同步的CPU密集型操作（签名计算+JSON序列化）包装成异步，但在ASP.NET环境下，这种做法完全没有收益：

• ASP.NET的请求线程来自线程池，Task.Run会把计算任务转交给另一个线程池线程，原请求线程会一直等待这个任务完成，并没有释放线程去处理其他请求。相比同步版本，只是多了一次线程切换的开销，反而降低了整体性能。
• 异步在ASP.NET中的核心价值是处理IO密集型操作（比如数据库查询、远程API调用），此时请求线程会被暂时释放，直到IO操作完成，这样线程池可以同时处理更多并发请求。但你的场景是纯CPU计算，完全不涉及IO，异步优化在这里起不到任何作用。

2. 当前的异步实现不规范，属于典型反模式 #

用Task.Run包装同步方法来实现“异步”是ASP.NET异步编程的常见错误：

• 它违背了异步编程的设计初衷，没有真正利用异步IO的优势，只是做了表面的异步包装。
• 正确的异步实现应该优先使用SDK提供的原生异步API：如果Cloudinary的SDK有SignParametersAsync这类异步签名方法，直接调用并await它才是规范的做法。如果没有原生异步方法，那保持同步版本反而更合理，没必要强行异步。

另外还要注意：你的异步版本里多了JsonConvert.SerializeObject步骤，同步版本是直接返回SignParameters的结果，这会导致两个版本返回的签名内容格式不一致，属于逻辑错误，需要修正。

内容的提问来源于stack exchange，提问作者chuckd