c# 如何处理高并发

高并发需分任务类型、选对机制、避默认陷阱：用异步I/O替代同步阻塞，ValueTask减GC压力，ReaderWriterLockSlim优化读多写少，CPU密集任务控并行度，热点数据缓存+消息队列分流，压测须真实连接级。

高并发不是“加线程就完事”，而是要分清任务类型、选对机制、避开默认陷阱。C# 里真正扛住万级 QPS 的系统，几乎从不靠 Thread.Start() 或盲目 Task.Run()，而是组合使用异步 I/O、并发集合、轻量同步和架构分流。

async/await 不是语法糖，是 I/O 并发的唯一正解

如果你还在用 dbContext.SaveChanges() 同步写数据库，或用 HttpClient.GetStringAsync().Result 等响应，那你的服务在 200 并发时就可能线程池饥饿、响应延迟飙升甚至死锁。

• 所有外部调用（HTTP、DB、文件、Redis）必须走真正的异步 API：用 ToListAsync() 而非 ToLIst()，用 GetStreamAsync() 而非 GetResponse()
• 绝不能在 async 方法里调用 .Wait() 或 .Result —— ASP.NET Core 中这会直接卡死请求上下文
• 高频小响应（如鉴权、计数器）优先用 ValueTask 替代 Task，避免 GC 压力（比如每秒 10 万次 token 校验，ValueTask 可减少 30%+ 内存分配）

public async ValueTask IsUserActiveAsync(int userId)
{
    // ✅ 正确：异步查缓存 + 异步查 DB（必要时）
    var cached = await _cache.GetAsync($"user:active:{userId}");
    if (cached.HasValue) return cached.Value;
return await _db.Users
    .Where(u => u.Id == userId && u.Status == "Active")
    .AnyAsync();
}
别乱锁，先看是不是真需要“写”——读多写少场景用 ReaderWriterLockSlim
很多人一遇到并发就上 lock(obj)，结果整个方法变成串行瓶颈。其实 80% 的共享状态是“读远多于写”，比如配置项、用户权限白名单、限流计数器。

							

								
								

									开源电子商务系统(网店) iWebShop
									
iWebShop基于iWebSI框架开发，在获得iWebSI技术平台库支持的条件下，iWebShop可以轻松满足用户量级百万至千万级的大型电子商务网站的性能要求。站点的集群与分布式技术（分布式计算与存储/高可用性/负载均衡）被屏蔽在SI 平台之内，基于iWebShop并且按照SI平台库扩展规范开发的新增功能模块，也将同时获得这种超级计算与处理的能力。作为开源的LAMP电子商务系统，iWebShop
								
								下载 
							
						


lock 是排他锁，读操作也得排队；而 ReaderWriterLockSlim 允许多个读同时进行，只在写时阻塞全部读写
注意：它不自动释放，必须配对 EnterReadLock()/ExitReadLock() 或用 using 模式（.NET 6+ 支持 using var _ = rwLock.EnterReadLock();）
如果只是计数累加，优先用 Interlocked.Increment(ref count) —— 零锁、原子、比 lock 快 5–10 倍

CPU 密集任务别扔进线程池，用 Parallel + 显式控制并发度
把图像压缩、JSON 解析、规则引擎计算这类 CPU 绑定任务丢进 Task.Run()，等于主动制造线程风暴。16 核机器跑 100 个 Task.Run(() => HeavyCalc())，结果是上下文切换压垮吞吐。

用 Parallel.ForEach(source, new ParallelOptions { MaxDegreeOfParallelism = Environment.ProcessorCount }) 控制并行数
大集合处理优先用 PLINQ：data.AsParallel().Where(...).Select(...).ToArray()，但注意它默认不保留顺序，且异常会包装成 AggregateException

更重的任务（如批量报表生成）应剥离到后台服务 + 消息队列，Web 层只返回 “任务已提交，ID: xxx”，避免占用请求线程

单机扛不住？那就别硬扛——用分布式缓存 + 消息队列做“软性分流”
再优化的代码也抵不过一个没缓存的热点查询（比如首页 Banner），或一个同步发邮件的接口。高并发的本质不是“让单机更快”，而是“让不该在请求链路里做的事，根本不出现在链路里”。

用户会话、商品详情、配置中心数据 → 全部进 Redis，设置合理过期时间，用 IDistributedCache 接口解耦
订单创建后发短信、更新搜索索引、扣减库存 → 封装成消息，投递到 RabbitMQ 或 Kafka，由独立消费者处理
千万别在 HTTP 请求里直接 await _queue.PublishAsync(msg) 后等 ACK —— 改为 fire-and-forget（或至少设超时 100ms），失败由死信队列兜底

最常被忽略的一点：高并发问题往往不是出在“怎么写”，而是出在“怎么测”。本地用 HttpClient 循环发 1000 次请求 ≠ 真实并发 —— 缺少连接复用、TCP 拥塞、服务端队列积压都测不出来。上线前务必用 wrk 或 hey 做真实连接级压测，并监控 ThreadPool.GetAvailableThreads() 和 GC 代龄分布。