Spring Boot 虚拟线程实战ThreadLocal 串数据、连接池打爆、synchronized 钉住线程三个坑及解决方案目录一、虚拟线程是什么二、Spring Boot 如何开启虚拟线程三、坑一ThreadLocal 数据串了四、坑二数据库连接池被打爆五、坑三synchronized 钉住平台线程六、全面检查清单七、总结一、虚拟线程是什么Java 21 在 2023 年 9 月正式发布了虚拟线程Virtual ThreadsJEP 444。它的核心突破在于一个虚拟线程占用的内存从传统平台线程的约 1MB 降到几百字节创建和切换的成本极低。传统平台线程 虚拟线程 ┌──────────────┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ... (几十万个) │ Thread A │ │v1│ │v2│ │v3│ │v4│ │ - 1MB 内存 │ └─┬┘ └─┬┘ └─┬┘ └─┬┘ │ - OS 调度 │ │ │ │ │ └──────────────┘ ▼ ▼ ▼ ▼ ┌──────────────────────┐ │ 平台线程池几个线程 │ │ - 只负责执行不绑定 │ └──────────────────────┘这意味着你可以同时处理几万甚至几十万个并发任务而不需要庞大的线程池。二、Spring Boot 如何开启虚拟线程Spring Boot 从 3.2 版本开始支持虚拟线程。开启方式极其简单2.1 配置启用# application.yml spring: threads: virtual: enabled: true开启后以下组件会自动使用虚拟线程组件默认线程模型开启后Tomcat/Jetty 请求处理平台线程池默认 200虚拟线程Async任务执行SimpleAsyncTaskExecutor虚拟线程Scheduled定时任务单线程调度虚拟线程RabbitMQ/Kafka 监听器SimpleMessageListenerContainer虚拟线程需单独配置2.2 手动创建虚拟线程// 方式一Thread.ofVirtual() Thread vt Thread.ofVirtual() .name(my-virtual-thread) .start(() - System.out.println(Hello from virtual thread)); // 方式二Executors.newVirtualThreadPerTaskExecutor() try (var executor Executors.newVirtualThreadPerTaskExecutor()) { executor.submit(() - doWork()); }三、坑一ThreadLocal 数据串了3.1 问题场景很多项目用 ThreadLocal 存储请求上下文当前用户、traceId 等public class UserContext { private static final ThreadLocalString currentUser new ThreadLocal(); public static void setUser(String userId) { currentUser.set(userId); } public static String getUser() { return currentUser.get(); } public static void clear() { currentUser.remove(); } } // 拦截器中设置 Override public boolean preHandle(HttpServletRequest request, ...) { UserContext.setUser(request.getHeader(X-User-Id)); return true; } Override public void afterCompletion(...) { UserContext.clear(); // 传统做法请求结束清理 }传统线程下一个请求从头到尾绑定同一个平台线程setUser(A)后整个请求期间getUser()都返回 A最后clear()清理——没问题。虚拟线程下一个虚拟线程可能在执行到一半时被挂起比如等待数据库响应此时底层的平台线程被释放去执行另一个虚拟线程。如果另一个虚拟线程也调用了setUser(B)平台线程上的 ThreadLocal 值就被覆盖了。当虚拟线程 A 恢复执行时它读到的可能是 B。时间线 t1: 虚拟线程v1 被调度到平台线程P1 → setUser(userA) t2: v1 发起数据库查询被挂起 → P1 被释放 t3: 虚拟线程v2 被调度到 P1 → setUser(userB) t4: v1 数据库返回恢复执行 → getUser() userB ← 串了3.2 解决方案ScopedValueJava 21ScopedValue是专门为虚拟线程设计的不可变上下文传递机制public class UserContext { private static final ScopedValueString CURRENT_USER ScopedValue.newInstance(); // 在 ScopedValue 的作用域内执行代码 public static T T withUser(String userId, SupplierT action) { return ScopedValue.where(CURRENT_USER, userId).call(action::get); } public static String getUser() { return CURRENT_USER.isBound() ? CURRENT_USER.get() : unknown; } } // 使用方式 —— 不是 set/get而是 where().call() GetMapping(/orders) public ListOrder list(RequestHeader(X-User-Id) String userId) { return UserContext.withUser(userId, () - orderService.queryOrders()); }ThreadLocal vs ScopedValue 对比特性ThreadLocalScopedValue绑定对象线程任务/作用域虚拟线程安全❌ 不安全✅ 安全可变性可读写不可变set 后不可改清理需手动 remove()作用域结束自动清理性能稍快略慢但有作用域隔离保障3.3 过渡方案用 InheritableThreadLocal 行吗不推荐。InheritableThreadLocal只在创建子线程时复制一次不适用于虚拟线程的挂起/恢复场景。四、坑二数据库连接池被打爆4.1 问题场景虚拟线程让 Tomcat 能同时处理几千个请求但数据库连接池通常只配了 20-50 个连接// HikariCP 默认配置 spring.datasource.hikari.maximum-pool-size20当 1000 个虚拟线程同时到达一个需要数据库查询的接口时1000 个请求 → 1000 个虚拟线程 → 1000 个 getConnection() ↓ 1967 只有 20 个连接 ↓ 980 个线程在等连接 ↓ 30 秒后超时 → 980 个 5004.2 解决方案方案 ASemaphore 限流推荐Component public class OrderService { // 限制最多 40 个并发数据库操作 private final Semaphore dbSemaphore new Semaphore(40); public ListOrder queryOrders(Long userId) { dbSemaphore.acquire(); try { return orderMapper.selectByUserId(userId); } finally { dbSemaphore.release(); } } }方案 B调整连接池大小spring: datasource: hikari: maximum-pool-size: 100 # 从 20 调大到 100但这只是推迟问题——请求量再大一些100 也不够。信号量是治本方案。方案 C请求入口限流// 用 Bucket4j 或 Guava RateLimiter 在 Controller 层限流 GetMapping(/orders) RateLimit(permitsPerSecond 100) public ListOrder list() { ... }4.3 什么资源需要加保护资源典型并发上限是否需要信号量数据库连接池20-100✅ 必须Redis 连接池50-200✅ 建议下游 HTTP 服务视对方而定✅ 建议本地计算无限制❌ 不需要五、坑三synchronized 钉住平台线程5.1 问题场景虚拟线程在执行 I/O 操作时会自动挂起、释放平台线程让其他虚拟线程运行。但有一个例外如果虚拟线程在synchronized块内遇到 I/O它无法挂起——平台线程被「钉住」pinned。public synchronized void processOrder(Order order) { // ↑ 获取了对象锁 orderMapper.insert(order); // DB I/O —— 虚拟线程本应挂起 notificationService.send(order); // HTTP I/O —— 又应挂起 // 但因为 synchronized虚拟线程被钉在平台线程上 // 这两个 I/O 操作期间平台线程白白等着 }5.2 解决方案用 ReentrantLockprivate final ReentrantLock lock new ReentrantLock(); public void processOrder(Order order) { lock.lock(); try { orderMapper.insert(order); // ✅ I/O 期间虚拟线程能挂起 notificationService.send(order); // ✅ 平台线程被释放 } finally { lock.unlock(); } }5.3 锁类型与虚拟线程兼容性锁类型虚拟线程能否在 I/O 时挂起建议synchronized❌ 不能避免在同步块内做 I/OReentrantLock✅ 能替代 synchronizedSemaphore✅ 能限流场景首选ReadWriteLock✅ 能读写分离场景StampedLock✅ 能高性能读写锁5.4 如何检测 pinned 事件# 开启 pinned thread 监控 logging: level: jdk: trace # 或通过 JFR 事件 jdk.VirtualThreadPinned启动时加 JVM 参数java -Djdk.tracePinnedThreadsfull -jar app.jar当虚拟线程被钉住时会打印完整栈信息到标准输出。六、全面检查清单开启虚拟线程前后逐项检查1. ThreadLocal □ 项目里有哪些 ThreadLocal □ 每个 ThreadLocal 的值在请求生命周期内是否可能被覆盖 □ 是否可以用 ScopedValue 替换 2. 连接池 / 外部资源 □ 数据库连接池 max-size 是多少够用吗 □ Redis / Kafka / RabbitMQ 的连接池呢 □ 高并发接口是否有信号量保护 3. 同步锁 □ 搜索项目里所有 synchronized → 内有 I/O 操作吗 □ 能换成 ReentrantLock 吗 4. 线程休眠 □ 有没有 Thread.sleep() → 虚拟线程下不需要 □ 有没有 ThreadLocal 依赖线程名称 → 虚拟线程名是动态的 5. 监控 □ 有没有开启 pinned thread 日志 □ 连接池等待队列是否有监控告警七、总结虚拟线程带来的不是「免费的性能提升」而是一次并发模型的切换。三个核心坑都源于同一个事实虚拟线程打破了「一个任务 一个平台线程」的绑定关系。坑根因方案ThreadLocal 串数据虚拟线程挂起/恢复时换平台线程换成 ScopedValue连接池打爆虚拟线程数 连接池大小Semaphore 限流synchronized 钉住synchronized 阻止虚拟线程挂起换成 ReentrantLock这三个检查做完你的 Spring Boot 项目就能放心开启虚拟线程了。带来的好处是实打实的——同等硬件下并发能力提升 5-10 倍。文章摘要本文系统梳理了 Spring Boot 启用虚拟线程Java 21后最常见的三个坑ThreadLocal 数据串扰、数据库连接池被海量虚拟线程打爆、synchronized 导致虚拟线程无法挂起pinned。每个坑都给出了根因分析、代码示例和解决方案ScopedValue 替代 ThreadLocal、Semaphore 限流保护连接池、ReentrantLock 替代 synchronized文末附完整的开启前检查清单。适合正在或计划在生产环境启用虚拟线程的 Java 后端开发者。