Linux中捕获SIGQUIT并触发线程Dump的本质是依赖JVM等运行时的内置响应，而非用户自定义处理；若用signal/sigaction注册handler会覆盖默认dump行为，导致失效；正确做法是保持SIG_DFL，直接发送kill -3或按Ctrl+\。
Linux中捕获SIGQUIT并触发线程Dump，本质不是“用自定义信号处理函数来生成dump”，而是让目标进程（尤其是Java等运行时环境）在收到SIGQUIT时自动执行其内置的Dump逻辑。用户无需、也不应手动注册sigaction去“实现dump”，否则反而会覆盖默认行为，导致dump失效。
为什么不该用signal/sigaction拦截SIGQUIT
多数语言运行时（如JVM）已为SIGQUIT预设了标准响应：打印线程栈快照（thread dump）。一旦你调用signal(SIGQUIT, my_handler)或sigaction注册自己的处理函数，就覆盖了JVM的默认动作，系统不再执行dump，只会运行你的空函数或任意逻辑——这恰恰破坏了调试目的。
- JVM默认将SIGQUIT视为“请求线程快照”信号，不依赖用户代码，由运行时内部直接响应
- POSIX规定，对已由运行时接管的信号，用户自定义handler会完全取代默认行为
- 即使你在handler里手动调用
pthread_kill或尝试触发jstack，也无法复现原生dump的上下文完整性与时机准确性
正确触发线程Dump的操作方式
保持SIGQUIT的默认处理动作（SIG_DFL），直接向进程发送信号即可：
- 终端前台进程：运行中按 Ctrl+\（反斜杠），JVM/Python等会立即输出thread dump到标准错误（stderr）
-
后台进程或远程场景：使用
kill -3 <pid></pid>（-3即SIGQUIT编号），例如：kill -3 12345 -
Java专用确认：确保JVM未禁用该功能（默认开启）；若用
-XX:+DisableExplicitGC等参数不影响SIGQUIT dump
验证和排查常见问题
如果执行kill -3后无输出，检查以下几点：
- 目标进程是否真的收到了信号？可用
strace -p <pid> -e trace=rt_sigprocmask,rt_sigaction</pid>观察信号处理注册状态 - 输出是否被重定向？JVM dump默认写stderr，若启动时重定向了
2>/dev/null，则看不到内容 - 权限是否足够？普通用户只能向同组/自己启动的进程发信号；root可向任意进程发送
- 进程是否屏蔽了SIGQUIT？极少见，但可通过
/proc/<pid>/status</pid>中SigBlk字段确认
特殊情况：需要在自定义handler中补救
仅当程序本身已注册了SIGQUIT handler（比如某个C服务），又想兼容dump功能时，可在handler内主动调用外部工具：
- 在C handler中执行
execl("/usr/bin/jstack", "jstack", pid_str, (char*)NULL)（需fork子进程，避免阻塞） - 更稳妥做法是：改用其他信号（如SIGUSR1）作为“触发dump”的自定义入口，保留SIGQUIT给JVM原生使用
- Java应用还可通过JMX或
jcmd <pid> Thread.print</pid>替代信号方式，完全绕过信号干扰
