使用信号量控制线程池任务提交速率的一个坑

本文探讨了使用信号量控制线程池任务提交速率的方法,并分析了一段具体代码出现错误的原因。介绍了SynchronousQueue的工作原理及其与ThreadPoolExecutor的交互过程,并提出了两种解决方案。
摘要由CSDN通过智能技术生成

​0 背景

不久前,标哥(此乃一位技术非常厉害的我的同事)曾让我看过一段很有意思的代码。这段代码的目的是通过信号量控制向线程池中提交任务,避免在线程池中大量积压任务影响程序执行效率。

我简化了一下,大概的逻辑如下:

// 实际工作的线程数,假设是4
static final int THREAD_CNT = 4;
public static void doWork() throws InterruptedException {
    // 使用了核心线程数和最大线程数都为4,且使用SynchronousQueue作为等待队列的线程池
    ThreadPoolExecutor executor = new ThreadPoolExecutor(THREAD_CNT, THREAD_CNT, 0l, TimeUnit.MINUTES, new SynchronousQueue<>());
    // 使用令牌数等于线程数,都是4的信号量控制任务提交速率
    Semaphore semaphore = new Semaphore(THREAD_CNT);
    while (true) {
        semaphore.acquire();
        executor.execute(() -> {
            // 这里面是业务逻辑,假设是打印时间戳
            System.out.println(System.currentTimeMillis());
            semaphore.release();
        });
    }
}

在提交任务的主线程中调用Semaphore.acquire(),在具体的执行线程执行结束时调用Semaphore.release()方法。

这段代码跑起来后,立刻就报错了:

这是为啥呢?

1 SynchronousQueue

SynchronousQueue有一对方法:

  • offer():向队列中插入元素,如果有线程等待获取则插入成功,否则插入失败;

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

镜悬xhs

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值