并发调试工具入门：GDB调试多线程程序、pdb调试Python并发代码、日志追踪与时间戳分析

并发程序出问题了，最头疼的是什么？

不是代码逻辑复杂，而是它不一定会复现。你今天跑得好好的，明天一上线就崩了。我遇到过太多次这种事了——一个多线程服务在测试环境稳如老狗，一上生产就随机挂。你盯着代码看半天，觉得哪哪都对，但程序就是不给你面子。

这时候，你就得靠工具了。说白了，调试并发程序，跟破案差不多。你得有线索，得有工具，还得有经验。今天我就把这三样东西给你捋一遍。

GDB调试多线程程序：C/C++工程师的救命稻草

先说说GDB。很多人觉得GDB就是用来设断点、看变量的。其实在并发场景下，GDB能做的事情远不止这些。

核心思路：多线程调试的关键在于——你能看到每个线程在干什么，以及它们之间怎么互相影响的。

我个人习惯，遇到多线程死锁或者数据竞争，第一件事就是 attach 到进程上，看看所有线程的堆栈。命令很简单：

# 启动程序
gdb ./my_server

# 查看所有线程
(gdb) info threads

# 切换到指定线程
(gdb) thread 2

# 查看当前线程的堆栈
(gdb) bt

# 查看所有线程的堆栈（这个我常用）
(gdb) thread apply all bt

嗯，这里要注意一点。当你用 thread apply all bt 的时候，输出可能会很长。我建议你配合 set pagination off 一起用，不然一页一页翻起来很烦。

我在项目中遇到过一个问题：一个多线程的缓存服务，偶尔会卡死。用GDB attach上去一看，两个线程都在等同一个锁。但锁的持有者是谁？用 thread apply all bt 扫了一遍，发现第三个线程卡在了一个文件IO操作上，锁一直没释放。这就是典型的——你以为的并发问题，其实是IO阻塞导致的。

小技巧：GDB里可以用 set scheduler-locking on 来让调试器只运行当前线程。这样你可以一步步跟踪某个线程的执行路径，不会被其他线程打断。但要注意，这可能会改变程序的执行时序，导致问题不出现。

还有一个我常用的命令：watch。比如你想知道某个共享变量什么时候被修改了：

(gdb) watch my_shared_var
(gdb) continue

一旦有线程修改了这个变量，GDB就会停下来，告诉你哪个线程干的。这在排查数据竞争时特别好用。

pdb调试Python并发代码：别怕，它也能用

Python的并发调试，说实话比C/C++要友好一些。但很多人觉得pdb只能调试单线程，其实不是的。

Python的 threading 模块和 multiprocessing 模块，都可以配合pdb来调试。不过有个坑——如果你直接在主线程里设断点，子线程的异常你是抓不到的。

我一般这么干：

import threading
import pdb

def worker():
    # 在子线程里主动启动pdb
    pdb.set_trace()
    # 你的业务逻辑
    do_something()

t = threading.Thread(target=worker)
t.start()
t.join()

这样每个子线程都能进入调试模式。但说实话，如果线程多了，这种方式会乱成一锅粥。我建议你只在怀疑有问题的线程里加 pdb.set_trace()。

注意：pdb在调试多线程时，n（next）和 s（step）命令只影响当前线程。其他线程仍然在后台运行。这意味着你单步调试的时候，程序状态可能已经被其他线程改变了。这一点跟GDB的 scheduler-locking 机制不同。

对于 asyncio 的并发调试，我推荐用 aiomonitor 或者 asyncio.debug。Python 3.7+ 可以这样开启：

import asyncio
import sys

# 开启asyncio调试模式
asyncio.run(main(), debug=True)

开启后，Python会输出更多关于事件循环的信息，比如哪些协程被阻塞了，哪些任务执行时间过长。我在调优一个WebSocket服务时，就是靠这个发现了一个协程卡在数据库查询上，导致整个事件循环被拖慢。

日志追踪与时间戳分析：最朴素也最有效

说实话，很多时候你没法在生产环境上挂GDB或者pdb。那怎么办？日志。

日志这东西，看着简单，但用好了是真能救命。我见过太多人写日志就是 print("here")，然后出了事一脸懵。

并发场景下的日志，有几个关键点：

每条日志都要带时间戳，精确到毫秒甚至微秒
每条日志都要带线程ID或协程ID，不然你分不清是谁打的
日志要有上下文，比如请求ID、用户ID，方便串联

我常用的日志格式：

2024-01-15 14:23:45.123 [Thread-3] [req_id=abc123] 开始处理订单
2024-01-15 14:23:45.456 [Thread-3] [req_id=abc123] 查询库存完成
2024-01-15 14:23:45.789 [Thread-7] [req_id=def456] 开始处理订单
2024-01-15 14:23:46.012 [Thread-3] [req_id=abc123] 扣减库存成功

你看，有了这些信息，你就能画出时间线。哪个请求慢？哪个线程在等什么？一目了然。

我的习惯：在关键操作前后各打一条日志，记录时间差。比如数据库查询前打一条，查询后打一条。这样你就能精确知道每个操作花了多久。我曾经用这个方法，发现一个“慢查询”其实不是SQL慢，而是连接池满了在排队。

时间戳分析还有个高级用法——时序图。你可以把日志导出来，用脚本分析每个线程的时间线，看看有没有重叠、有没有等待。我写过一个小工具，把日志里的时间戳和线程ID提取出来，生成一个简单的时序图：

Thread-1:  ----[查询]----[处理]----[写入]----
Thread-2:       ----[查询]----[等待锁]--------[处理]----
Thread-3:            ----[查询]----[处理]----[写入]----

看到Thread-2的“等待锁”了吗？这就是性能瓶颈。你都不用看代码，光看日志就知道问题在哪。

知识体系总览

下面这张图，是我自己总结的并发调试工具全景。你可以把它当成一个检查清单——遇到问题，先看属于哪一类，再选对应的工具。

你看这张图，三个工具各有各的适用场景。GDB适合底层C/C++的并发问题，pdb适合Python的线程和协程调试，日志追踪则是万能的——虽然信息量少一些，但胜在可以上生产环境。

避坑指南：我曾经在生产环境上直接attach GDB到一个高并发的服务进程，结果GDB停住所有线程的那一瞬间，客户端超时了。嗯，从那以后我学乖了——生产环境上，能用日志解决的，绝不用调试器。实在要用，也得先确认对业务的影响。

最后说一句：工具是死的，人是活的。你掌握了这些工具，更重要的是培养一种并发思维——遇到问题，先想清楚是死锁、数据竞争、还是性能瓶颈，然后再选工具。别一上来就GDB attach，也别一上来就加一堆日志。先分析，再动手。

想要更多资料，联系可可

📚 课程目录

并发调试工具入门：GDB调试多线程程序、pdb调试Python并发代码、日志追踪与时间戳分析

GDB调试多线程程序：C/C++工程师的救命稻草

pdb调试Python并发代码：别怕，它也能用

日志追踪与时间戳分析：最朴素也最有效

知识体系总览