GDB-Detach并非独立命令，而是指快速attach进程、采集栈信息后立即detach的轻量调试策略，核心是“快进、快看、快出”，全程全自动控制在3秒内，避免冻结线上业务。
不能用 gdb -p 直接 attach 卡死进程并长期挂载——这会冻结进程，线上业务无法承受。所谓“GDB-Detach”不是独立命令，而是指用 gdb 临时 attach、快速采集信息后立即 detach，全程不中断进程运行。核心思路是：**快进、快看、快出**。
一、先确认进程是否真卡死，且可被安全 attach
执行前务必检查两点：
- 用
ps -o pid,stat,comm -p <pid></pid>查状态：若为 D（uninterruptible sleep），gdb 无法 attach，别试；若为 T（stopped）或 S/R（sleeping/running），可继续 - 权限要匹配：必须是同一用户启动的进程，或用
sudo gdb -p <pid></pid>；非 root 用户需提前确认/proc/sys/kernel/yama/ptrace_scope值为 0（线上慎改）
二、用 gdb 快速 attach + 打印全栈 + 立即 detach
整套操作控制在 3 秒内，原进程几乎无感知：
sudo gdb -p <pid> -ex "thread apply all bt -n 15" -ex "detach" -ex "quit"</pid>-
-ex表示执行一条 gdb 命令；bt -n 15只打 15 层栈，避免模板展开拖慢速度 -
detach主动断开，不等用户输入；quit退出 gdb，整个流程全自动 - 输出直接打印到终端，可重定向保存：
... > stack_$(date +%s).log 2>&1
三、替代方案：比 attach 更轻量、更安全的 pstack
如果只是看“卡在哪”，pstack 是首选——它本质调用 gdb，但封装得更克制，不加载符号表、不接管进程控制流：
- 确保已安装 gdb：
sudo apt install gdb（Debian/Ubuntu）或sudo yum install gdb（CentOS/RHEL） - 直接运行：
pstack <pid></pid>，1 秒内返回所有线程当前函数调用路径 - 看到多个线程都停在
pthread_mutex_lock、__lll_lock_wait或sem_wait，基本可判定用户态死锁 - 若函数名显示为
??，说明缺少调试符号，不影响定位阻塞点，但建议上线前部署.debug包
四、当 gdb/pstack 都卡住时：转向 /proc 接口取内核态快照
若 gdb -p 或 pstack 自身卡住超过 5 秒，进程大概率已陷入内核态不可中断状态（如磁盘 IO 卡死、驱动 hang、D 状态），此时 gdb 无能为力：
- 查内核堆栈：
cat /proc/<pid>/stack</pid>—— 显示每个线程在内核中阻塞的位置（如pipe_wait、do_readv、ext4_file_read_iter） - 查等待原因：
cat /proc/<pid>/status | grep -E 'State|Tgid|PPid|voluntary_ctxt_switches|nonvoluntary_ctxt_switches'</pid>，结合State: D和高nonvoluntary_ctxt_switches可佐证内核卡死 - 查系统调用阻塞点：
sudo strace -p <pid> -qq -e trace=none 2>&1 | head -n 1</pid>，常能看到反复出现的futex(… FUTEX_WAIT_PRIVATE …)或read(19, …，直接指出锁地址或 fd
