信号量与线程调度关系详解

从现在开始，努力学习吧！本文《Semaphore原理与线程调度关系解析》主要讲解了等等相关知识点，我会在golang学习网中持续更新相关的系列文章，欢迎大家关注并积极留言建议。下面就先一起来看一下本篇正文内容吧，希望能帮到你！

本文深入解析 `Semaphore` 在 `ExecutorService` 环境下的实际行为机制，澄清“为何 `availablePermits()` 永远不会输出 3”，并通过代码执行时序还原其内部许可获取/释放逻辑，帮助开发者正确理解信号量的并发控制本质。

Semaphore(3) 表示系统最多允许 3 个线程同时持有许可（即并发执行临界区代码）。关键在于：availablePermits() 返回的是当前 未被任何线程持有 的许可数，而每个正在执行 acquire() → 临界区 → release() 流程的线程，都必然已占用 1 个许可。

在您的代码中，5 个 Callable 任务几乎同时提交给 newFixedThreadPool(5)，线程池会立即启动最多 5 个线程尝试执行。由于 acquire() 是阻塞操作，前 3 个抢先执行的线程（如 thread-1、thread-2、thread-3）成功获取许可，此时 availablePermits() == 0。随后线程进入 Thread.sleep(1000) 和 System.out.println() —— 这些耗时操作为线程调度创造了大量切换窗口。

此时，第 4 个线程（如 thread-4）仍在 acquire() 处等待；当任一先行线程（如 thread-3）完成 sleep 并调用 release() 后，许可数变为 1，thread-4 被唤醒并立即获得该许可，随即执行 availablePermits() —— 此刻它看到的是 剩余许可数 = 总许可数（3）− 当前已持有许可的线程数（2） = 1（因为 thread-1 和 thread-2 仍处于 sleep 或打印阶段，尚未 release）。

同理，当 thread-4 执行到 availablePermits() 时，可能 thread-1 已 release，但 thread-2 和 thread-4 自身正持有许可，故结果为 1；最终 thread-5 执行该方法时，若仅它自己持有许可（其余均已释放），则 3 − 1 = 2 —— 因此 availablePermits() 的最大可能值永远是 2，绝不可能是 3，因为调用它的线程自身必然已持有一个许可。

以下是修正后的演示代码，添加了时间戳和线程状态标记，使执行逻辑更清晰：

public class SemaphoreDemo {
    private final Semaphore semaphore = new Semaphore(3);

    public void doit() {
        List<String> data = List.of("1", "2", "3", "4", "5");
        List<Callable<String>> tasks = new ArrayList<>();

        for (String s : data) {
            tasks.add(() -> {
                System.out.printf("[%s] %s: attempting acquire...%n",
                        new Date(), Thread.currentThread().getName());
                semaphore.acquire(); // 阻塞直到获得许可
                System.out.printf("[%s] %s: acquired, available=%d%n",
                        new Date(), Thread.currentThread().getName(),
                        semaphore.availablePermits());

                String result = s + "@" + Thread.currentThread().getName();
                Thread.sleep(1000); // 模拟业务耗时
                System.out.printf("[%s] %s: processing '%s'%n",
                        new Date(), Thread.currentThread().getName(), result);

                semaphore.release(); // 归还许可
                System.out.printf("[%s] %s: released, available=%d%n",
                        new Date(), Thread.currentThread().getName(),
                        semaphore.availablePermits());
                return result;
            });
        }

        ExecutorService executor = Executors.newFixedThreadPool(5);
        try {
            List<Future<String>> futures = executor.invokeAll(tasks);
            for (Future<String> f : futures) {
                System.out.println("Result: " + f.get());
            }
        } catch (Exception e) {
            e.printStackTrace();
        } finally {
            executor.shutdown();
        }
    }

    public static void main(String[] args) {
        new SemaphoreDemo().doit();
    }
}

✅ 核心结论总结：

• Semaphore(3) ≠ “最多打印 3 次”，而是“最多 3 个线程可同时进入临界区”；
• availablePermits() 的值 = 3 − 当前持有许可的线程数，调用该方法的线程自身必占 1 个许可，故输出范围恒为 [0, 2]；
• 输出顺序高度依赖线程调度时机，属非确定性行为，不可用于逻辑判断；
• acquire()/release() 必须严格配对，建议使用 try-finally 或 try-with-resources（配合 Semaphore.Permit）防止许可泄露。

? 典型应用场景与 API 建议：

• 限流控制：如限制数据库连接池、HTTP 客户端并发请求数（OkHttp 的 ConnectionPool 内部使用类似机制）；
• 资源池管理：自定义对象池（如 ObjectPool）中协调空闲实例的分配与回收；
• 协作式同步：替代 wait()/notify() 实现多线程步调协调（例如生产者-消费者中控制缓冲区容量）；
• JDK 内置依赖：java.util.concurrent 中 ThreadPoolExecutor 的 workQueue 拒绝策略、ForkJoinPool 的任务窃取调度均隐式借鉴信号量思想。

掌握 Semaphore 的本质，关键在于跳出“锁”的思维定式——它不是互斥锁（ReentrantLock），而是计数型许可控制器，适用于“N选M”而非“独占临界区”的并发场景。

本篇关于《信号量与线程调度关系详解》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！