刚看到个贴子，说某大厂花月薪6万挖来个技术大牛，结果俩月不到就跟部门负责人杠上了，就因为他几乎不加班。贴子里意思大概是：老板觉得你拿高薪就该996，人家大牛觉得只要活干完，凭啥拿时间表演忠诚。

　　网友评论我看了看，有的夸大牛有骨气，有的骂他不懂规则。我觉得这事吧，谁也没绝对对错，但底线得说清：公司买的是你的“结果”，不是你在工位上坐多久。反过来，大牛拿了这个价，就得把价值拉满，让别人闭嘴，而不是光靠情绪硬刚。

　　换个角度想，大厂也该反思，真想留牛人，就别只会用加班衡量忠诚。能把制度谈清楚，把目标说白了，彼此尊重，才有可能双赢。

　　那天晚上快十一点，我在公司楼下啃着个凉掉的汉堡，我们组小李突然发微信问我： “哥，你刷到那个打印零和奇偶数的并发题没？我脑袋都打结了……”

　　我一看题目名字，还以为是啥小学数学，结果点开一看：典型面试高频并发题，用 Java 写的那种。

　　有三个线程：

　　线程 A：只负责打印 0

　　线程 B：只负责打印奇数 1、3、5、7…

　　线程 C：只负责打印偶数 2、4、6、8…

　　给你一个正整数 n，要求 最终输出的顺序 长这样：

　　0 1 0 2 0 3 0 4 0 5 ...

　　一直到 n，比如 n = 5，就得打印：

　　0 1 0 2 0 3 0 4 0 5

　　注意几个点：

　　三个线程是并发启动的

　　但是打印顺序必须像上面那样严格交替

　　你不能用“一个线程全干了”这种耍赖操作，面试官要看的是并发控制能力

　　我当时在楼下跟小李语音说：这个题其实就两个事：

　　谁先动

　　打完以后该轮到谁

　　只要这俩事控制住了，代码就很自然了。

　　这个题我比较喜欢用 Semaphore 来写，语义很清楚，相当于发令牌：

　　zero 信号量：轮到打印 0 的时候才放行

　　odd 信号量：轮到打印奇数的时候才放行

　　even 信号量：轮到打印偶数的时候才放行

　　想象一下： 零号线程手里一开始有“通行证”，先打印 0，然后根据当前要打的数字是奇数还是偶数，把通行证交给对应的线程。 奇数 / 偶数线程打完自己的数字，再把通行证还给零号线程。

　　就这么个轮流借钥匙的游戏。

　　直接上完整 Java 代码，先看一眼整体长啥样，再慢慢拆：

　　import java.util.concurrent.Semaphore;import java.util.function.IntConsumer;publicclassZeroEvenOdd{privatefinalint n;// 一开始只允许打印 0 的线程运行，所以给 1 个许可privatefinal Semaphore zero = new Semaphore(1);// 奇数、偶数线程一开始都不许动privatefinal Semaphore odd = new Semaphore(0);privatefinal Semaphore even = new Semaphore(0);publicZeroEvenOdd(int n){this.n = n;}// 打印 0 的线程publicvoidzero(IntConsumer printNumber)throws InterruptedException {for (int i = 1; i <= n; i++) {zero.acquire; // 等待轮到自己printNumber.accept(0); // 打印 0// 下一个应该打印奇数还是偶数？if ((i & 1) == 1) {odd.release; // 奇数线程可以动了} else {even.release; // 偶数线程可以动了}}}// 打印奇数的线程publicvoidodd(IntConsumer printNumber)throws InterruptedException {for (int i = 1; i <= n; i += 2) {odd.acquire; // 等待零线程发牌printNumber.accept(i); // 打印当前奇数zero.release; // 轮到零线程}}// 打印偶数的线程publicvoideven(IntConsumer printNumber)throws InterruptedException {for (int i = 2; i <= n; i += 2) {even.acquire; // 等待零线程发牌printNumber.accept(i); // 打印当前偶数zero.release; // 轮到零线程}}// 简单跑一下看看效果publicstaticvoidmain(String[] args){ZeroEvenOdd zeo = new ZeroEvenOdd(5);IntConsumer printer = x -> System.out.print(x + " ");Thread tZero = new Thread( -> {try {zeo.zero(printer);} catch (InterruptedException ignored) { }});Thread tOdd = new Thread( -> {try {zeo.odd(printer);} catch (InterruptedException ignored) { }});Thread tEven = new Thread( -> {try {zeo.even(printer);} catch (InterruptedException ignored) { }});tZero.start;tOdd.start;tEven.start;}}

　　简单讲下这个逻辑为啥能稳住顺序，不靠运气：

　　谁先动？ zero 信号量初始值是 1，说明打印 0 的线程一开始就能 acquire 成功，先打印第一个 0。 odd / even 初始值是 0，它们一开始 acquire 一定会阻塞。

　　打印 0 之后怎么办？ 零线程里有个循环 for (int i = 1; i <= n; i++) ，每次打印完一个 0，就看一下当前要配对的数字是奇数还是偶数：

　　如果是奇数，把 odd 的许可加 1

　　如果是偶数，把 even 的许可加 1 这就相当于：“下一位同学请上台”。

　　奇数 / 偶数线程干嘛？ 它们的套路是一样的：

　　先在自己对应的信号量上 acquire 一下

　　被唤醒之后打印数字

　　打完之后再把通行证还给 zero ： zero.release ，让 0 可以继续打印

　　为什么不会乱序？ 即使三个线程是并发抢 CPU 的，但它们有“钥匙”这一层约束： 没拿到自己这把信号量，就只能老老实实 acquire 阻塞，轮不到你，你就进不来。 所以最终顺序一定是： zero → odd / even → zero → odd / even … 这样交替。

　　这个题面试的时候还有个常见坑：有人会想着用 synchronized + wait/notify 写，也能写，但状态控制会复杂一点，要维护“当前轮到谁”“当前数字是奇是偶”之类的状态变量，写着写着容易绕进去。

　　Semaphore 这种“发令牌”的思路，脑子里画个时间线就很清楚：

　　零线程像个调度中心

　　奇数 / 偶数线程像两个工人

　　调度中心每次先打个 0，然后指定下一个该谁干活

　　小李那天听完在语音那边“哦——”了一声，回去十分钟就把题敲出来了。 你要是哪天面试碰到这道，脑子里想一下“借钥匙”的画面，基本就不会慌。

　　行了，先这样，我去热个夜宵，你要是想看 wait/notify 写法，下次咱再聊。