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

关键信息解读：

快速识别主线程的技巧：

1. 主线程通常是第一个创建的线程（Id=1）
2. 主线程的调用栈会包含main()函数
3. 在 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 典型线程类型：

常见阻塞场景分析：

1. 主线程卡在epoll_wait：

   • 正常状态：等待客户端连接/命令
   • 异常情况：如果长时间不返回，可能网络层有问题

2. 工作线程卡在pthread_cond_wait：

   • 正常状态：等待后台任务（如AOF持久化）
   • 异常情况：条件变量未被触发，可能死锁

3. 线程卡在锁竞争：

   #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

模式说明：

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 响应变慢，通过以下步骤定位：

1. 附加 GDB 后立即中断

2. 查看所有线程状态

   (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

   看起来主线程在正常等待

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

   (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

4. 查看调用栈

   (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 源码分析，可能是事件处理耗时过长

5. 检查慢查询日志

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

   确认是否有耗时命令

线程调试速查表

常用 GDB 多线程命令总结：

Redis 关键线程函数：

掌握这些技巧后，下次遇到 Redis 性能问题，你就能像专业医生一样，快速找到"病灶"所在。记住，多线程调试的关键是保持耐心，一次只专注一个线程的问题。