自定义线程池限速，实战并发控制技巧

本文深入探讨了在高并发场景下如何通过多种灵活、安全的限速策略实现精细化的线程池并发控制，强调“任务提交前限速”优于修改线程池本身的硬性约束；无论是基于Semaphore按用户ID等维度实现秒级配额限流，还是借助RateLimiter令牌桶应对突发流量、保障平滑吞吐，亦或在线程池执行阶段动态感知负载并反向调控，乃至与Dubbo等RPC框架深度集成实现全链路、可灰度、可监控的统一限速，都提供了即开即用的实战方案和关键避坑指南——让你在不牺牲稳定性与扩展性的前提下，真正掌控每一份并发资源的流向与节奏。

直接在任务提交前加一层限速控制，比修改线程池本身更安全、更灵活。核心思路是：不靠压低线程数硬限流，而是对“任务进入队列”这个动作做节制。

用信号量（Semaphore）做每秒任务配额

适合对某类关键变量（如用户ID、订单号、接口路径）按单位时间限速的场景。例如限制每个用户每秒最多提交3个查询任务：

• 声明一个ConcurrentHashMap，key为变量标识（如"uid_12345"），value为对应信号量
• 初始化时设置permits=3，公平模式可选
• 提交任务前调用semaphore.tryAcquire()，成功才submit；失败则走降级（返回缓存、延迟重试或拒绝）
• 搭配定时清理过期key（比如10分钟无访问的uid自动移除Semaphore），避免内存泄漏

基于令牌桶实现平滑限速

比信号量更贴近真实流量模型，尤其适合突发流量下保持稳定吞吐。可用Guava的RateLimiter或自研轻量桶：

• 为每个变量创建独立RateLimiter，如RateLimiter.create(5.0)表示每秒5个令牌
• 任务提交前调用limiter.tryAcquire()，返回true才进线程池；false时可sleep再重试，或直接丢弃
• 注意RateLimiter不是线程安全的跨实例共享对象，每个变量需独占一个实例
• 若变量维度高（如百万级用户），建议配合LRUMap限制最大缓存数量，避免OOM

在线程池执行阶段拦截并动态调节

适用于需要根据运行时指标（如队列积压、响应延迟）反向调控特定变量任务的场景：

• 继承ThreadPoolExecutor，重写beforeExecute()方法，在真正执行前检查该任务所属变量的当前负载
• 维护一个ConcurrentMap记录各变量最近10秒已执行任务数，超阈值则抛出RejectedExecutionException触发拒绝策略
• 配合CallerRunsPolicy，让提交线程自己执行任务，天然形成背压，避免队列无限堆积
• 拒绝后可记录日志+上报监控，用于后续容量评估

与Dubbo等框架协同限速

如果变量来自RPC上下文（如Dubbo的attachment），可在Filter层统一拦截：

• 编写自定义Dubbo Filter，在invoke前提取关键变量（如method、appKey）
• 查本地限速规则（可从Apollo/Nacos动态加载），匹配后走上述任一限速逻辑
• 把限速结果通过RpcContext.getServerAttachment()透传到服务端，服务端线程池再做二次校验
• 这样限速逻辑与业务代码解耦，且支持灰度开关和实时生效

今天关于《自定义线程池限速，实战并发控制技巧》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！