Linux下没有自动生成的死锁报告，能否看到警告取决于是否启用lockdep（内核态）或JVM检测（Java用户态）；lockdep需编译时开启CONFIG_LOCKDEP=y和CONFIG_PROVE_LOCKING=y，在dmesg输出“possible circular locking dependency”等警告而非结构化报告；用户态C/C++死锁无日志，需pstack/gdb等工具手动抓栈分析；Java则由JVM主动检测并生成“Found one Java-level deadlock”可读报告。
Linux 下没有“运行产生死锁后自动生成的调试报告”这种东西——死锁本身不会触发日志输出，除非内核或用户态程序主动做了检测和上报。是否能看到报告，取决于你是否提前启用了对应检测机制，以及死锁发生在哪一层（内核态 or 用户态）。
内核态死锁：靠 lockdep 输出 WARN 而不是“报告”
lockdep 是内核内置的锁依赖跟踪器，它不生成独立报告文件，而是在触发死锁条件时直接打印到 dmesg 缓冲区：
- 必须在编译内核时开启：
CONFIG_LOCKDEP=y、CONFIG_PROVE_LOCKING=y - 运行时不能动态开启，只能通过内核启动参数临时启用（不推荐生产环境）
- 死锁未真正发生前，
lockdep就能检测到潜在循环依赖并报WARNING: possible circular locking dependency detected
查看方式就是：
dmesg | grep -i "deadlock\|lockdep\|circular"-
dmesg -T | tail -50（带时间戳，方便定位发生时刻）
注意：这类输出不是结构化“报告”，而是内核 panic 前的 warning 日志，内容包含锁类名、调用栈、持有/请求关系。如果系统已卡死且无法敲命令，需从串口或 /var/log/kern.log（若 syslog 持续工作）中提取。
用户态死锁：没有自动报告，只有阻塞现象 + 工具抓现场
C/C++ 程序用 pthread_mutex_lock 陷入死锁时，glibc 不会报错、不写日志、不中断线程——它就卡在 futex 系统调用里，安静等待。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
你能拿到的“现场信息”全靠外部工具实时捕获：
-
pstack <PID>：快速看所有线程当前调用栈，重点找多个线程都停在__pthread_mutex_lock或futex_wait_queue_me -
cat /proc/<PID>/stack：更底层的内核栈，确认是否真卡在 futex 等待 -
ps -eo pid,lwp,stat,wchan:30,cmd | grep <PID>：看线程状态（D或S）和等待通道（wchan），多个线程同在do_futex就高度可疑 -
gdb -p <PID>→thread apply all bt：比pstack更准，能显示具体锁变量地址（如mutex1、mutex2）
这些都不是“报告”，而是原始诊断快照。你需要人工比对：谁持有了哪把锁、谁在等哪把锁、顺序是否交叉（AB/BA）。
Java 进程死锁：有标准报告，但只限 JVM 层面
Java 是个例外——JVM 自带死锁检测，且能生成可读性强的诊断信息：
- 触发条件：两个以上线程互相持有 monitor 并等待对方 monitor
- 查看方式：
-
jstack <PID>：输出中会有明确段落Found one Java-level deadlock:，列出线程、锁对象、等待链 -
jcmd <PID> VM.native_memory summary（辅助看内存是否异常） - 如果启用了 JFR（Java Flight Recorder），可通过
jfr dump提取锁争用事件
-
注意：JVM 只管 Java 对象锁（synchronized、java.util.concurrent），不管 JNI 调用的 native 锁（比如 pthread_mutex）。后者仍需用 pstack/gdb 查。
关键点在于：Linux 本身不提供“死锁报告服务”。所谓“报告”，要么是内核 lockdep 的 dmesg 警告，要么是 JVM 主动扫描的结果，要么是你用工具手动抓取的线程栈快照。没人替你做归因分析——谁持有什么锁、为什么循环等待，得你自己对照源码和栈帧推出来。
