GDB 多线程调试实战：3步定位 Redis 4.0 主线程与工作线程阻塞点-平芜编程栈

GDB 多线程调试实战：3步定位 Redis 4.0 主线程与工作线程阻塞点

当 Redis 服务器突然响应变慢时，作为开发者最头疼的就是不知道问题出在哪里。是主线程卡住了？还是某个工作线程出了问题？本文将带你用 GDB 快速定位 Redis 多线程程序中的阻塞点，就像给程序做一次精准的"CT扫描"。

1. 准备工作：启动 Redis 并附加 GDB

首先确保你已经编译了带调试信息的 Redis 4.0。如果是从源码编译，记得加上-g选项：

make CFLAGS="-g -O2"

启动 Redis 服务器，建议使用开发模式以便观察日志：

src/redis-server --loglevel debug

在另一个终端，用ps命令找到 Redis 的进程 ID：

ps aux | grep redis-server

然后附加 GDB：

gdb -p <redis-pid>

注意：生产环境谨慎使用 GDB 附加，可能会引起服务短暂停顿

2. 线程状态快速诊断

在 GDB 中，最核心的命令就是info threads。这个命令会显示所有线程的状态快照：

(gdb) info threads Id Target Id Frame 4 Thread 0x7fffef7fd700 (LWP 53065) "redis-server" 0x00007ffff76c4945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 3 Thread 0x7fffefffe700 (LWP 53064) "redis-server" 0x00007ffff76c4945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 2 Thread 0x7ffff07ff700 (LWP 53063) "redis-server" 0x00007ffff76c4945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 * 1 Thread 0x7ffff7fec780 (LWP 53062) "redis-server" 0x00007ffff73ee923 in epoll_wait () from /lib64/libc.so.6

关键信息解读：

列名	说明	示例值
Id	GDB 内部线程编号	1-4
Target Id	系统级线程标识	LWP 53062
Frame	线程当前执行位置	epoll_wait

快速识别主线程的技巧：

主线程通常是第一个创建的线程（Id=1）
主线程的调用栈会包含main()函数
在 Redis 中，主线程会阻塞在epoll_wait等待网络事件

3. 深入分析线程堆栈

确定了可疑线程后，切换到该线程查看完整调用栈。比如我们怀疑线程2有问题：

(gdb) thread 2 [Switching to thread 2 (Thread 0x7ffff07ff700 (LWP 53063))] #0 0x00007ffff76c4945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 (gdb) bt #0 0x00007ffff76c4945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x000000000047a91c in bioProcessBackgroundJobs (arg=0x0) at bio.c:176 #2 0x00007ffff76c0e25 in start_thread () from /lib64/libpthread.so.0 #3 0x00007ffff73ee34d in clone () from /lib64/libc.so.6

Redis 4.0 典型线程类型：

线程ID	线程类型	典型阻塞点	相关源码文件
1	主线程	epoll_wait	ae.c, networking.c
2-4	BIO线程	pthread_cond_wait	bio.c

常见阻塞场景分析：

主线程卡在epoll_wait：
- 正常状态：等待客户端连接/命令
- 异常情况：如果长时间不返回，可能网络层有问题
工作线程卡在pthread_cond_wait：
- 正常状态：等待后台任务（如AOF持久化）
- 异常情况：条件变量未被触发，可能死锁

线程卡在锁竞争：

#0 0x00007ffff76c4a5d in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x00007ffff76c02cb in pthread_mutex_lock () from /lib64/libpthread.so.0

这种情况表明存在锁竞争，需要分析哪个线程持有锁

4. 高级调试技巧

4.1 锁定调试线程

默认情况下，GDB 会在所有线程间切换。要专注于当前线程：

(gdb) set scheduler-locking on

模式说明：

模式	效果	适用场景
off	所有线程自由运行	默认状态
on	仅当前线程运行	单线程调试
step	单步时锁定当前线程	精确控制

4.2 条件断点

在特定线程上设置断点：

(gdb) break bio.c:180 thread 2

或者在所有线程设置断点：

(gdb) break bio.c:180 thread all

4.3 观察共享变量

Redis 有很多全局变量，观察它们的变化：

(gdb) watch server.blocked_last_cron

当变量被修改时，GDB 会自动暂停并显示修改的线程和堆栈。

实战案例：诊断 Redis 慢查询

假设我们发现 Redis 响应变慢，通过以下步骤定位：

附加 GDB 后立即中断

查看所有线程状态

(gdb) info threads Id Target Id Frame * 1 Thread 0x7ffff7fec780 (LWP 53062) "redis-server" 0x00007ffff73ee923 in epoll_wait () from /lib64/libc.so.6 2 Thread 0x7ffff07ff700 (LWP 53063) "redis-server" 0x00007ffff76c4945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0

看起来主线程在正常等待

让程序继续运行几秒后再次中断

(gdb) continue ^C (gdb) info threads Id Target Id Frame * 1 Thread 0x7ffff7fec780 (LWP 53062) "redis-server" 0x00000000004265df in aeApiPoll (tvp=0x7fffffffe300, eventLoop=0x7ffff08350a0) at ae_epoll.c:112 2 Thread 0x7ffff07ff700 (LWP 53063) "redis-server" 0x00007ffff76c4945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0

发现主线程现在卡在aeApiPoll

查看调用栈

(gdb) bt #0 0x00000000004265df in aeApiPoll (tvp=0x7fffffffe300, eventLoop=0x7ffff08350a0) at ae_epoll.c:112 #1 0x0000000000426aeb in aeProcessEvents (eventLoop=0x7ffff08350a0, flags=11) at ae.c:411 #2 0x00000000004238ef in main (argc=1, argv=0x7fffffffe648) at server.c:3899

结合 Redis 源码分析，可能是事件处理耗时过长

检查慢查询日志

(gdb) p server.slowlog_entry_count $1 = 5 (gdb) p server.slowlog[0]

确认是否有耗时命令

线程调试速查表

常用 GDB 多线程命令总结：

命令	作用	示例
info threads	查看所有线程	info threads
thread	切换线程	thread 2
thread apply cmd	对指定线程执行命令	thread apply 2 bt
set scheduler-locking	控制线程调度	set scheduler-locking on
break ... thread	线程特定断点	break foo.c:123 thread 2