前言
最近看到社区都在讨论 JDK 25 和 WebFlux（图一），很多老兵都在纠结： “我们真的需要为了异步而异步吗？”
作为一名在 Java 圈摸爬滚打 9 年的“老司机”，我一直奉行：技术是用来解决生产问题的，而不是用来增加心智负担的。 既然 Spring Boot 4.0 已经全面拥抱虚拟线程（Virtual Threads），那我们之前的那些“高并发套路”也该翻新了。今天不聊空洞理论，直接上代码，复盘我上周在生产环境重构分布式限流组件的过程。
所属专栏： [Java 高并发架构实战：从青铜到王者]
一、 痛点回溯：为什么传统的线程池限流“不香了”？
在过去，我们处理高并发限流，通常是 Sentinel + Semaphore 或者自定义线程池。
- 线程切换成本：在高 QPS 场景下，内核态与用户态的上下文切换（Context Switch）开销大得惊人。
- I/O 阻塞死锁：当 Redis 响应稍慢，线程池瞬间打满，导致系统雪崩（还记得我之前写的《微服务雪崩救星：Sentinel 实战》吗？）。
二、 方案升级：虚拟线程 + Lua 脚本
这次我抛弃了复杂的响应式编程（WebFlux 虽好，但调试起来真的头大），直接用了 Java 21 的虚拟线程。
- 核心逻辑：利用虚拟线程“轻量、阻塞不占资源”的特性，配合 Redis 的 Lua 脚本实现原子限流。
- 代码片段（满足主人对完整代码的偏好）：
📄 点击展开：完整代码 (VThreadLimiter.java)
import org.springframework.data.redis.core.StringRedisTemplate;
import org.springframework.data.redis.core.script.DefaultRedisScript;
import java.util.Collections;
import java.util.concurrent.Executors;
/**
* 虚拟线程下的分布式限流实战
* 结合 Java 21 与 Redis Lua
*/
public class VThreadLimiter {
private final StringRedisTemplate redisTemplate;
private final String LIMIT_LUA =
"local key = KEYS[1] " +
"local limit = tonumber(ARGV[1]) " +
"local current = tonumber(redis.call('get', key) or '0') " +
"if current + 1 > limit then return 0 " +
"else redis.call('INCRBY', key, 1) " +
"redis.call('expire', key, 1) return 1 end";
public VThreadLimiter(StringRedisTemplate redisTemplate) {
this.redisTemplate = redisTemplate;
}
public void executeTask(String userId, Runnable task) {
// 使用虚拟线程池，告别固定线程池的资源争抢
try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
executor.submit(() -> {
if (acquire(userId)) {
try {
task.run();
} finally {
// 业务逻辑执行完后的清理
}
} else {
System.err.println(" [!] 被限流了，用户ID: " + userId);
}
});
}
}
private boolean acquire(String key) {
DefaultRedisScript<Long> script = new DefaultRedisScript<>(LIMIT_LUA, Long.class);
Long result = redisTemplate.execute(script, Collections.singletonList("rate_limit:" + key), "100");
return result != null && result == 1L;
}
}
三、 避坑指南：虚拟线程不是万能药！
在重构过程中，我踩了 3 个血泪坑（图二风格）：
- ThreadLocal 陷阱：虚拟线程中大量使用 ThreadLocal 会导致内存膨胀，建议改用 Scoped Values。
- Synchronized 锁定问题：在 synchronized 块中执行 I/O 会导致虚拟线程“钉”在 OS 线程上，导致失效。记得改用 ReentrantLock。
- 连接池调优：不要用原来的数据库连接池配置，虚拟线程并发量级不同，连接池瞬间会被掏空！
四、 总结：拥抱 AI 与新版本
现在的趋势是“Java + Go + AI”（图一），AI 可以帮我们写 CRUD，但这种高并发下的分布式一致性处理、锁竞争优化，依然是架构师的核心护城河。
如果你也对生产环境的“血泪经验”感兴趣，欢迎订阅我的专栏： 《Java 高并发架构实战：从青铜到王者》 。下一篇预告：《从源码到压测：为什么你的 @Transactional 在虚拟线程下失效了？》
