原文来自于：https://zha-ge.cn/java/73

99% 的人没搞懂：Semaphore 到底是干啥的？

有次组里聚餐，聊着聊着突然绕到了多线程的“老三样”——synchronized、Lock、还有一个神秘的Semaphore。
说起前两个，大伙点头如捣蒜。结果一问Semaphore，全桌人突然鸦雀无声，场面一度非常尴尬。

Semaphore，究竟是只什么“妖”

打个比方，Semaphore就像是景区门口的检票员。这个景区昼夜24小时营业，门口最多只能放进N个人。每进来一个，检票员记一次，进满后只能等人出来，剩下的人只能在门口干瞪眼。出了一个，检票员挥手：可以进一个新的啦！

用程序话说，Semaphore其实最适合用在“限流或者控制并发访问数量”的场景。比如线程池里，你不想让太多线程同时访问一段敏感代码，就塞个Semaphore。

实操：抢茅坑的名额

有段日子新项目量大，大家都有点上头。偏巧需求搞了个“高并发抢资源”场景。我的第一反应是：线程同步加锁呗，谁怕谁？
可是！项目同事（技术雷达贼灵）提醒说：“兄弟，这个地方是要控制‘一组线程里只能有三个人同时进’，用Semaphore不是刚刚好？”
Emmmm，细想也是哈。

搞了两行代码，思路清晰无比：

Semaphore semaphore = new Semaphore(3); // 最多能有3人占坑
semaphore.acquire(); // 没坑就等
try {
    // ……“抢坑”逻辑……
} finally {
    semaphore.release(); // 用完要让座
}

结果代码一上，就像给茅坑贴了计数牌，谁也进不来多的。

踩坑瞬间

说起来简单，真用的时候还真有俩小坑：

• 手欠忘了 release
  有次测试数据突然卡死，大家都傻眼。后来才发现：一哥们写完业务逻辑直接return，中间忘了release，茅坑永远“被站住”，后来只能重启服务祭天。

• 不懂公平性
  Semaphore 默认是“非公平”模式，也就是新来的未必排在等候区最前。领导强行搞“先到先得”，切了“公平”模式，结果性能直接暴跌……
  小伙伴一顿 Google，才明白：公平只是看起来“公平”，实际开销贼大！

• 误以为 release 一次一定对应 acquire 一次
  举个栗子，有同事搞了个循环释放，release 多次让名额飞涨，线程都涌进去了——排队机制直接失效，场面一度非常凶险。

再来点“暗黑代码”片段，未 release 的坑：

semaphore.acquire(); 
if(badLogic()) {
    return; // 忘记 release！造成死锁。
}
// ...
semaphore.release();

经验启示

满打满算，玩了几年Semaphore，最大的感觉就是：
它不是“线程互斥万能钥匙”，更多是“限流阀门”！

给大家总结几点血泪经验：

• 适用场景
  多线程限资源，比如数据库连接池、抢占物理资源、非全局锁场景。
• 一定仔细 release
  最好放 try-finally 里，不然真等着服务“假死”吧。
• 想要让线程“公平”进”？三思！
  性能真掉队，没极特殊需求建议别乱设成公平。
• 解释用法要用比喻
  不然很多同事还是以为是个奇怪的锁。

最后想说的是

写到这儿，其实就像亲身“抢茅坑”奋斗史，基本姿势一遍遍踩出血才明白——
Semaphore和加锁不是一回事，别哪都套上。

以后谁再问Semaphore干啥——你就说：“排队神器，放行计数，茅坑专用！”
没啥好玄乎的，真弄明白了，它可有趣