虚拟线程吃掉了我的内存？一个爬虫的并发之殇！

最新推荐文章于 2025-07-29 22:53:47 发布

Java八股文

最新推荐文章于 2025-07-29 22:53:47 发布

阅读量997

点赞数 16

CC 4.0 BY-SA版权

文章标签：爬虫

本文链接：https://blog.youkuaiyun.com/sc35262/article/details/149482613

虚拟线程来了，性能爆表！但没想到，这个“轻量级线程”一不小心就把内存吃爆了……一位开发者在构建 Web 爬虫时，就亲身体验到了这种“速度与内存”的极限拉扯。

这不是一篇吹捧虚拟线程的文章，而是一场关于 Java 新特性“翻车”的真实经历。从传统平台线程切换到虚拟线程，性能飞跃背后的隐患也悄然而至。

01 初始方案：传统平台线程的爬虫实现

为了测试并发能力，这位开发者实现了一个最基本的多线程爬虫，逻辑清晰简单：

使用固定线程池（200个平台线程）；
将要抓取的 URL 提交到线程池；
每个线程从本地模拟的 HTTP 服务器下载页面并执行处理；
使用 VisualVM 监控内存和处理速率。

代码片段如下所示：

private final ExecutorService executorService = Executors.newFixedThreadPool(200); ... CompletableFuture<?>[] futures = new CompletableFuture[urls.size()]; int index = 0; for (String url : urls) { futures[index++] = CompletableFuture.runAsync( () -> downloadAndProcess(url), executorService ); } CompletableFuture.allOf(futures).join();

数据源是 2 万个 URL，其中包括不同大小的静态文件，例如 1KB、10KB、100KB 乃至 1MB 的内容：

urls.addAll(List.of( "http://localhost:8080/data/1kb", "http://localhost:8080/data/10kb", "http://localhost:8080/data/100kb", "http://localhost:8080/data/1mb" ));

为了更贴近真实环境，还将 Java 堆最大值限制为 1GB，以模拟资源受限的场景。

运行结果：中规中矩，但稳定。

02 换上虚拟线程：速度起飞，内存炸裂！

接着，他将线程池替换为 Java 19+ 中的“每任务虚拟线程池”：

Executors.newVirtualThreadPerTaskExecutor()

起初一切看起来都很美好，页面下载速度飞快，仿佛 JVM 被施了魔法。

直到——

java.lang.OutOfMemoryError: Java heap space

原来，虚拟线程太快了！

平台线程因为 I/O 阻塞，自带“降速”功能；而虚拟线程几乎不会阻塞，一旦放开限制，下载速度直接拉满，处理线程根本来不及跟上，内存被瞬间塞爆！

这位开发者无奈感叹：爬虫不是挂了，是“炸了”。

03 为何虚拟线程反而更占内存？

来看下背后的机制：

特性	平台线程	虚拟线程
阻塞行为	会占用内核线程资源	会自动挂起，不占资源
默认并发限制	固定线程数限制任务提交速度	无默认并发上限
下载速度	网络 I/O 成为瓶颈	下载接近“瞬时完成”
处理速度	与下载同步前进	下载远超处理速度
内存压力	可控	极高，容易 OOM

结论是：虚拟线程太“能干”，导致任务涌入，超出 JVM 承受能力。

小贴士：平台线程受限，天然带有“背压”机制，而虚拟线程天马行空，需要人为加限制！

04 如何优雅控制虚拟线程并发？

虚拟线程不是不能用，而是要加“缰绳”。

✅ 方案一：用 Semaphore 限流

使用 Semaphore 控制并发任务数量，例如限制最多并发 500 个：

private final Semaphore concurrencyLimit = new Semaphore(500); private void downloadAndProcess(String url) { concurrencyLimit.acquire(); try { // 下载与处理逻辑 } finally { concurrencyLimit.release(); } }

每启动一个任务先获取许可，处理完释放许可。这样就不会有上万个线程同时塞满内存。