原文来自于:zha-ge.cn/java/73
99% 的人没搞懂:Semaphore 到底是干啥的?
有次组里聚餐,聊着聊着突然绕到了多线程的"老三样"------synchronized
、Lock
、还有一个神秘的Semaphore
。 说起前两个,大伙点头如捣蒜。结果一问Semaphore
,全桌人突然鸦雀无声,场面一度非常尴尬。
Semaphore,究竟是只什么"妖"
打个比方,Semaphore
就像是景区门口的检票员。这个景区昼夜24小时营业,门口最多只能放进N个人。每进来一个,检票员记一次,进满后只能等人出来,剩下的人只能在门口干瞪眼。出了一个,检票员挥手:可以进一个新的啦!
用程序话说,Semaphore
其实最适合用在"限流或者控制并发访问数量"的场景。比如线程池里,你不想让太多线程同时访问一段敏感代码,就塞个Semaphore
。
实操:抢茅坑的名额
有段日子新项目量大,大家都有点上头。偏巧需求搞了个"高并发抢资源"场景。我的第一反应是:线程同步加锁呗,谁怕谁? 可是!项目同事(技术雷达贼灵)提醒说:"兄弟,这个地方是要控制'一组线程里只能有三个人同时进',用Semaphore
不是刚刚好?" Emmmm,细想也是哈。
搞了两行代码,思路清晰无比:
java
Semaphore semaphore = new Semaphore(3); // 最多能有3人占坑
semaphore.acquire(); // 没坑就等
try {
// ......"抢坑"逻辑......
} finally {
semaphore.release(); // 用完要让座
}
结果代码一上,就像给茅坑贴了计数牌,谁也进不来多的。
踩坑瞬间
说起来简单,真用的时候还真有俩小坑:
-
手欠忘了 release 有次测试数据突然卡死,大家都傻眼。后来才发现:一哥们写完业务逻辑直接return,中间忘了release,茅坑永远"被站住",后来只能重启服务祭天。
-
不懂公平性 Semaphore 默认是"非公平"模式,也就是新来的未必排在等候区最前。领导强行搞"先到先得",切了"公平"模式,结果性能直接暴跌...... 小伙伴一顿 Google,才明白:公平只是看起来"公平",实际开销贼大!
-
误以为 release 一次一定对应 acquire 一次 举个栗子,有同事搞了个循环释放,release 多次让名额飞涨,线程都涌进去了------排队机制直接失效,场面一度非常凶险。
再来点"暗黑代码"片段,未 release 的坑:
java
semaphore.acquire();
if(badLogic()) {
return; // 忘记 release!造成死锁。
}
// ...
semaphore.release();
经验启示
满打满算,玩了几年Semaphore
,最大的感觉就是: 它不是"线程互斥万能钥匙",更多是"限流阀门"!
给大家总结几点血泪经验:
- 适用场景 多线程限资源,比如数据库连接池、抢占物理资源、非全局锁场景。
- 一定仔细 release 最好放 try-finally 里,不然真等着服务"假死"吧。
- 想要让线程"公平"进"?三思! 性能真掉队,没极特殊需求建议别乱设成公平。
- 解释用法要用比喻 不然很多同事还是以为是个奇怪的锁。
最后想说的是
写到这儿,其实就像亲身"抢茅坑"奋斗史,基本姿势一遍遍踩出血才明白------ Semaphore
和加锁不是一回事,别哪都套上。
以后谁再问Semaphore
干啥------你就说:"排队神器,放行计数,茅坑专用!" 没啥好玄乎的,真弄明白了,它可有趣