本文深入解析 `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，因为调用它的线程自身必然已持有一个许可。
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
以下是修正后的演示代码，添加了时间戳和线程状态标记，使执行逻辑更清晰：
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<T>）中协调空闲实例的分配与回收；
- 协作式同步：替代 wait()/notify() 实现多线程步调协调（例如生产者-消费者中控制缓冲区容量）；
- JDK 内置依赖：java.util.concurrent 中 ThreadPoolExecutor 的 workQueue 拒绝策略、ForkJoinPool 的任务窃取调度均隐式借鉴信号量思想。
掌握 Semaphore 的本质，关键在于跳出“锁”的思维定式——它不是互斥锁（ReentrantLock），而是计数型许可控制器，适用于“N选M”而非“独占临界区”的并发场景。
