测试服务对sigterm的响应时间，核心是测从发送信号到进程完全退出的用户态耗时，反映清理逻辑是否高效；需先确认服务已注册处理逻辑，再用time+kill端到端计时，并通过注入延迟、系统工具等验证健壮性与根因。
测试服务对 SIGTERM 的响应时间，核心不是测“信号送达内核”的延迟（那是微秒级、不可控的），而是测**从发送 SIGTERM 到进程完全退出所经历的用户态耗时**——这反映的是服务自身清理逻辑是否高效、有无阻塞或等待。这个时间直接影响服务滚动更新、容器重启等场景的可靠性。
确认服务已注册 SIGTERM 处理逻辑
先验证服务是否真的捕获并响应 SIGTERM，而非直接走默认终止（那样就没有“响应时间”可言，是瞬间退出）。方法包括：
- 查看服务源码或文档：确认调用了
sigaction(SIGTERM, &sa, NULL)或类似注册逻辑，且处理函数中包含明确的清理步骤（如关闭监听套接字、刷写缓冲区、等待子任务完成） - 用
strace -e trace=signal,exit_group your_service启动服务，再发kill -TERM $pid，观察是否触发了自定义 handler 而非直接exit_group - 检查进程是否忽略或屏蔽了 SIGTERM：
cat /proc/$pid/status | grep Sig，关注SigBlk（阻塞掩码）和SigCgt（已捕获信号位图），SIGTERM 对应位 15，若SigCgt第 15 位为 1，说明已注册处理函数
使用 time + kill 组合进行端到端计时
这是最常用、最贴近真实运维场景的测试方式。重点在于精确捕捉“进程消失”的时刻：
- 启动服务并记录 PID：
./myserver & echo $! > /tmp/server.pid - 用
time包裹kill -TERM并等待进程退出：time (kill -TERM $(cat /tmp/server.pid) && while kill -0 $(cat /tmp/server.pid) 2>/dev/null; do sleep 0.01; done) - 该命令输出的 real 时间即为响应时间。注意
sleep 0.01提供 10ms 精度，对大多数服务足够；若需更高精度，可用inotifywait监控/proc/$pid消失，或用timeout配合循环检测
注入可控延迟以验证清理逻辑健壮性
单纯测“正常退出”不够，要验证服务在压力下是否仍能及时响应。可在处理函数中模拟常见阻塞点：
- 添加人工延迟（仅测试用）：
sleep(2)或usleep(500000)模拟慢速资源释放，再重复上述time测试，确认延迟能被准确捕获 - 模拟 I/O 阻塞：在 handler 中打开一个大文件并调用
fsync()，观察响应时间是否随文件大小线性增长 - 模拟网络等待：启动一个后台 goroutine 或子进程，在 handler 中等待其结束，人为设置超时（如
select { case ），验证超时机制是否生效
结合系统工具定位长延迟根因
若实测响应时间远超预期（如几秒甚至几十秒），需进一步排查卡点：
- 用
gdb -p $pid连上去，执行thread apply all bt查看所有线程当前堆栈，确认是否卡在锁、IO、条件变量等待上 - 用
perf record -e syscalls:sys_enter_kill,syscalls:sys_exit_kill -p $pid抓取 kill 系统调用路径，确认信号是否被成功注入 - 检查是否有未阻塞的信号干扰：若服务在 handler 中调用了非异步信号安全函数（如
malloc,printf），可能引发死锁或挂起，此时需用sigprocmask在关键临界区临时屏蔽 SIGTERM
