进程不发出硬件中断，中断由硬件设备主动产生，内核响应后通过信号（如SIGINT）通知进程；可通过/proc/interrupts查看中断来源与频率，用strace跟踪进程收信，perf监控中断影响。
进程本身不“发出”系统中断，中断是由硬件设备（如键盘、网卡、定时器）主动产生的电信号，内核响应后才通知相关进程——比如通过发送信号（如 SIGINT）来间接反映中断事件。因此，**不能直接查看“某个进程发出了什么中断”**，但你可以观察中断活动如何影响进程行为，或追踪哪些中断被触发、由哪个设备引起。
看硬件中断来源和频率：/proc/interrupts
这是最直接的方式，显示每个 CPU 上各类中断（IRQ）的触发次数及关联设备：
- 运行 cat /proc/interrupts，每行第一列是 IRQ 编号，后面是各 CPU 的中断计数，末尾通常标有设备名（如 eth0、i8042（键盘控制器）、timer）
- 重复执行几次并对比数值变化，可判断哪个设备正在活跃触发中断（例如网卡收包多 → eth0 计数上涨快）
- 注意：同一 IRQ 可能被多个设备共享（尤其在老旧系统），需结合 lspci -v 或 cat /proc/tty/drivers 进一步确认归属
查进程收到的信号（中断的软件映射）
硬件中断常转化为信号送达进程。要确认进程是否因中断而收到信号，可关注：
- kill -l 列出所有信号，理解常见映射关系： • Ctrl+C → SIGINT (2)（键盘中断触发） • 定时器到期 → SIGALRM (14) • 子进程退出 → SIGCHLD (17)（由内核在进程管理中断中生成）
- 用 strace -p PID 实时跟踪某进程的系统调用与信号接收，当它突然停在 --- SIGINT {si_signo=SIGINT, ...} --- 就说明刚收到了对应中断引发的信号
监控中断延迟与性能影响
高频中断可能抢占 CPU，拖慢进程。可通过以下方式评估影响：
- watch -n 1 'cat /proc/interrupts | head -20' 观察中断计数飙升是否伴随进程响应变慢
- 用 perf stat -e irq:softirq_entry,irq:hardirq_entry -p PID 统计指定进程运行期间被硬/软中断打断的次数（需 root 权限）
- 检查 /proc/PID/status 中的 voluntary_ctxt_switches 和 nonvoluntary_ctxt_switches：后者显著偏高，可能暗示频繁中断导致强制上下文切换
补充说明：为什么进程不“发出”中断
中断本质是硬件向 CPU 发起的异步请求，进程运行在软件层，无权直接触发硬件中断线。它只能：
- 发起系统调用（如 read()），由内核驱动在合适时机等待硬件中断（如磁盘 DMA 完成）后唤醒该进程
- 调用 kill() 或 raise() 发送信号——但这属于软件信号（software interrupt），不是硬件中断，也不经过 IRQ 控制器
- 设置定时器（setitimer）后，内核会在时钟中断处理中比对超时并投递 SIGALRM
