从职场吐槽到技术解耦：用Python threading.Event解决多线程顺序打印难题

刚看到一个讨论帖，内容是关于公司里一位博士同事的。帖子里吐槽他代码质量糟糕、不深入了解需求就匆忙动手，导致项目里埋了不少坑。尽管实际产出效果一般，但领导却颇为看重他。发帖人感慨道：学历真的太重要了。

翻看网友们的回复，观点五花八门：有人质疑博士的“含水量”，有人批评领导判断力，也有人说这就是“学历红利”。对此，我的看法是，问题不能简单地归咎于学历本身。学历作为一块招牌和入场券，其价值是客观存在的。但领导所看重的，或许远不止于此——背景资源、沟通能力、甚至是在关键时刻能“撑场面”的价值，这些隐性因素往往同样关键。代码质量不高固然不对，但如果我们只执着于“学历与能力不匹配”的愤懑，除了让自己心态失衡，并无实际益处。

从更建设性的角度看，与其纠结于他人的“不公”或“不行”，不如将焦点转向自身：什么是你不可替代的核心价值？深耕业务、保持稳定可靠的输出、建立团队信任，这些实打实的积累，远比单纯的吐槽更有力量。

算法题：按序打印

说到积累，昨晚加班时的一段对话让我印象深刻。快十一点了，办公室灯都熄了一半，只有我和组里的同事小李还在。他突然问我：“哥，你平时写多线程代码，怎么确保几个线程能按设定顺序执行打印啊？我这题总调成乱序。”

我一下子来了精神。先把问题翻译一下：有三个函数，first、second、third，它们会被三个不同的线程异步调用。线程的启动顺序是随机的，但要求打印输出的顺序必须是 first → second → third。题目通常使用 Python 环境。这意味着，我们需要在无法控制线程启动时机的情况下，严格管控它们的执行顺序。

这就像生活中排队，必须得有清晰的“轮到你了”的信号机制，否则一拥而上必然混乱。

我告诉小李，先别急着写代码，理清逻辑是关键。要实现顺序打印，本质上就两个“前置条件”：

1. second 必须等待 first 执行完毕。
2. third 必须等待 second 执行完毕。

逻辑很简单，难点在于如何让并发的线程“等待”同伴。在Python的 threading 模块中，有锁（Lock）、条件变量（Condition）、事件（Event）、信号量（Semaphore）等多种同步原语可用。为了便于理解，我选择用最直观的 threading.Event 来演示。

我在白板上写了下面这段代码，这个解法可以直接用于 LeetCode 上类似的“按序打印”题目：

from threading import Event, Thread

class Foo:
    def __init__(self):
        # first -> second 的“发令枪”
        self.second_ready = Event()
        # second -> third 的“发令枪”
        self.third_ready = Event()

    def first(self, printFirst):
        # printFirst() 输出 "first"
        printFirst()
        # 告诉 second：我干完了，你可以上了
        self.second_ready.set()

    def second(self, printSecond):
        # 等 first 把枪响了
        self.second_ready.wait()
        printSecond()
        # 告诉 third：轮到你了
        self.third_ready.set()

    def third(self, printThird):
        # 等 second 完成
        self.third_ready.wait()
        printThird()

# 下面只是一个简单的本地测试示例
if __name__ == "__main__":
    foo = Foo()

    def printFirst():
        print("first", end='')

    def printSecond():
        print("second", end='')

    def printThird():
        print("third", end='')

    t1 = Thread(target=foo.first, args=(printFirst,))
    t2 = Thread(target=foo.second, args=(printSecond,))
    t3 = Thread(target=foo.third, args=(printThird,))

    # 故意打乱启动顺序
    t3.start()
    t2.start()
    t1.start()

    t1.join()
    t2.join()
    t3.join()
    # 程序输出必然是：firstsecondthird

小李一看就明白了。Event 的核心操作就两个：wait() 和 set()。

• set()：可以理解为打开闸门，“放行”所有正在这个事件上 wait() 的线程。
• wait()：线程在此处“阻塞等待”，直到对应的事件被 set() 才继续执行。

所以，这个题的解决思路就是设置两道“闸门”：

• second 在闸门A（second_ready）前等待，first 执行完后打开闸门。
• third 在闸门B（third_ready）前等待，second 执行完后打开闸门。

只要这两道门顺序控制好，无论线程启动顺序如何，运行到 wait() 时都会被正确拦住，从而保证全局执行顺序。

随后，小李又提了一个经典问题：“那能不能不用 Event，用一个整型状态变量配合锁来实现呢？”当然可以，只是逻辑需要自己维护，稍微复杂一点。我又写了一个版本供他参考，如果你想深入理解同步原语，也可以看看：

from threading import Lock, Condition

class Foo2:
    def __init__(self):
        self.state = 1  # 1 表示该 first，2 表示该 second，3 表示该 third
        self.lock = Lock()
        self.cond = Condition(self.lock)

    def first(self, printFirst):
        with self.cond:
            # 肯定轮到 first 先执行，这里不用等
            printFirst()
            self.state = 2
            # 通知其他等待的线程：状态变了
            self.cond.notify_all()

    def second(self, printSecond):
        with self.cond:
            # 只要还没轮到 2，就一直等
            while self.state != 2:
                self.cond.wait()
            printSecond()
            self.state = 3
            self.cond.notify_all()

    def third(self, printThird):
        with self.cond:
            while self.state != 3:
                self.cond.wait()
            printThird()

这个写法有两个关键细节，很容易出错：

1. while self.state != ...: cond.wait() 这里必须使用 while 循环，而不是 if 判断。这是多线程编程的经典准则，因为线程被唤醒时，条件不一定满足（存在“虚假唤醒”可能），或者状态可能被其他线程再次改变。醒来后重新检查条件是必须的。
2. 所有对共享状态 self.state 的读写，都必须放在 with self.cond:（即获取锁）的上下文中。否则，在没有同步保护的情况下访问共享变量，会引发数据竞争，导致状态错乱和不可预知的执行顺序。

我对小李说，如果是应对面试算法题或快速实现需求，优先推荐 Event 方案，它更直观，不易出错。而 Condition 配合状态机的写法，更有助于理解同步机制的底层原理，未来遇到更复杂的“顺序控制”、“流量限制”或“批量任务唤醒”等场景时，这种模式便能复用了。

技术的精进往往在于将抽象的抱怨，转化为具体可解的问题。无论是职场困惑还是技术难题，在云栈社区这样的开发者聚集地，分享与探讨总能带来新的视角和更优的解决方案。