跳转到主内容
极星编程网:以代码为星,赴技术山海!

c#如何实现多线程爬虫_c#多线程爬虫的正确用法与注意事项

Task.Run + HttpClient 不能直接堆数量跑爬虫,因 HttpClient 共享连接池且默认连接上限低(.NET Framework 为2、Core/5+为10),盲目并发会触发 SocketException 或 Connection refused。 为什么
Task.Run
+
HttpClient
不能直接堆数量跑爬虫 因为
HttpClient
不是线程安全的实例,但更关键的是:它内部共享连接池,盲目开几百个
Task.Run
会迅速打满连接数、触发
SocketException: Too many open files
或
HttpRequestException: Connection refused
。默认连接池上限(
ServicePointManager.DefaultConnectionLimit
)在 .NET Framework 是 2,在 .NET Core/5+ 是 10,远低于你想象的“并发数”。 实操建议: 复用单个
HttpClient
实例(推荐声明为
static readonly
或注入
IHttpClientFactory
) 用
SemaphoreSlim
控制并发请求数,别依赖线程数——HTTP 请求大部分时间在等响应,不是 CPU 密集型 设置合理的
Timeout
和
MaxConnectionsPerServer
(通过
HttpClientHandler
配置) 避免在循环里 new
HttpClient
,否则 DNS 缓存不生效、TCP 连接无法复用
HttpClient
配合
SemaphoreSlim
的最小可靠写法 这是真正能控并发、防崩、可重试的组合。重点不是“多线程”,而是“可控并发 HTTP 请求流”。 示例逻辑(.NET 6+):
private static readonly HttpClient _client = new HttpClient(new HttpClientHandler { MaxConnectionsPerServer = 100 }); private static readonly SemaphoreSlim _semaphore = new SemaphoreSlim(10, 10); // 最多 10 个并发请求

public async Task FetchAsync(string url) { await _semaphore.WaitAsync(); try { var response = await _client.GetAsync(url, CancellationToken); response.EnsureSuccessStatusCode(); return await response.Content.ReadAsStringAsync(); } finally { _semaphore.Release(); } }

注意点:
SemaphoreSlim
必须是
static
,否则每个实例都独立计数,失去限流意义
CancellationToken
要传入
GetAsync
,否则
WaitAsync
被取消时,请求还在后台发着 别用
Task.WaitAll
等待一堆
Task.Run
,改用
Task.WhenAll
等待
FetchAsync
返回的
Task
遇到 429 / 503 / DNS timeout 怎么办 这不是代码写错了,是目标站点在反爬或限流。硬扛只会让请求全挂,得主动降频、错峰、伪装。 C知道 CSDN推出的一款AI技术问答工具 下载 实操建议: 检查响应头:
response.Headers.RetryAfter
存在就按它给的秒数 sleep,别自己瞎猜 对 429 响应统一加退避逻辑(比如指数退避
await Task.Delay(100 * (int)Math.Pow(2, retryCount))
) DNS 失败(
HttpRequestException
内嵌
SocketException
with code 11001)大概率是并发太高被运营商 DNS 限速,加随机 delay 或换 DNS(如 8.8.8.8)没用,本质要降并发 别只靠 User-Agent 伪装,加上
Accept
、
Accept-Language
、
Referer
才像真实浏览器请求 要不要用
Parallel.ForEach
或
PLINQ
不要。它们面向 CPU 密集型任务,而爬虫是 I/O 密集型。用
Parallel.ForEach
启动 100 个
GetAsync
,等于同时发起 100 个网络等待,不仅不提速,还会压垮连接池和本地端口(TIME_WAIT 爆满)。 正确姿势只有两个: 用
Task.WhenAll
+ 限流(如上
SemaphoreSlim
) 用
IAsyncEnumerable
+
Channel
做生产者-消费者模型,适合持续抓取、动态增减 URL 场景 真正的瓶颈从来不在“线程够不够”,而在“连接能不能复用”“请求有没有被限”“DNS 和 TLS 握手是否稳定”。把这三个点盯死,比调任何线程参数都管用。

相关文章