ADSP/ARM 性能/稳定性排查专栏总述

标签: 问题排查, 经验分享, 内存优化, 内存越界, 性能优化, 死机死锁

前言

在嵌入式开发领域，"经验" "专家"是一个经常被提及的词。但什么才是真正的工作经验？它绝不是简单地用工作年限来衡量的。

一个人工作了十年，如果每天都在做重复的业务逻辑开发，那么他的"经验"可能还不如一个认真钻研了三年底层问题的人。

真正的经验，来自于你在无数个深夜里对着串口日志分析死机原因，在一次次崩溃复现中总结出规律，在反复的性能调优中积累出对系统的深度理解。

这个专栏，正是基于这样的理念来写的------我希望把实际项目中遇到的各类"疑难杂症"以及对应的排查方法论系统性地整理出来，帮助更多的嵌入式工程师建立起自己的问题排查知识体系。

专栏定位

本专栏聚焦于 Android / ADSP/ Linux 嵌入式系统 的问题排查，主要覆盖以下三大方向：

一、内存问题

内存问题是嵌入式设备上最常见、也最难缠的一类问题。嵌入式设备的内存资源通常有限（几百 MB 甚至更少），一旦出现内存问题，轻则系统卡顿，重则直接 OOM Killer 杀进程导致功能异常。

本方向将覆盖以下内容：

内存越界（Heap Buffer Overflow）：写操作超出了分配的内存边界，破坏了相邻的内存数据，导致程序行为异常或者崩溃。
内存泄漏（Memory Leak）：申请的内存没有及时释放，长期运行后内存逐渐耗尽。
OOM 排查：当系统触发 OOM Killer 时，如何分析日志、定位元凶、制定优化策略。

相关的工具和方法包括 Valgrind、AddressSanitizer (ASan)、mtrace 等，我们会在后续文章中逐一详细讲解。

二、死机与死锁诊断

死机和死锁是嵌入式系统中另一类高频问题。这类问题的排查难度在于，问题发生后系统往往已经失去了正常的响应能力，常规的调试手段可能无法使用。

我们将重点讨论以下场景：

内核 Panic / Oops ：如何通过 dmesg、kallsyms、addr2line 等工具定位内核崩溃的位置。
用户态进程 Crash ：利用 core dump + gdb 进行事后分析，快速定位崩溃的代码行。
死锁（Deadlock） ：包括互斥锁死锁、读写锁死锁、自旋锁死锁等，使用 gdb 查看线程状态和锁持有情况。

三、性能优化

当嵌入式设备出现卡顿、响应慢、功耗高等问题时，就需要进行性能分析和优化。性能优化不是"拍脑袋"式的改动，而是需要基于数据驱动的系统性方法。

我们将讨论：

CPU 性能分析 ：使用 perf 工具进行热点函数分析、火焰图生成。
I/O 性能分析 ：使用 iostat、iotop、blktrace 等工具定位 I/O 瓶颈。
系统级分析 ：结合 strace、ftrace 等工具分析系统调用的耗时和频率。

工具矩阵

本专栏将系统性地介绍以下核心工具的使用方法和实战案例：

工具	用途	适用场景
gdb	程序调试、Crash 分析、死锁诊断	用户态调试、远程调试、Core Dump 分析
Valgrind	内存错误检测、内存泄漏检查	开发阶段的内存问题排查（性能开销较大）
ASan	内存越界、泄漏检测	编译时插桩，性能开销小（~2x），适合嵌入式场景
strace	系统调用跟踪	分析进程的系统调用行为
perf	CPU 性能分析	热点函数分析、火焰图、硬件计数器
addr2line	地址转源码行	崩溃日志中的地址解析
crash	内核 Crash 分析	内核态死机分析

方法论：系统化调试思维

工具只是手段，更重要的是建立系统化的调试思维。我总结了一套 "观察-假设-验证-总结" 的四步排查法：

1. 观察（Observe）

收集所有可以获取的信息：日志、调用栈、内存状态、CPU 使用率等。在这个阶段，不要急于下结论，而是尽可能全面地收集数据。

bash 复制代码

# 收集系统状态信息
cat /proc/meminfo
cat /proc/cpuinfo
dmesg | tail -100
ps aux --sort=-%mem

2. 假设（Hypothesize）

根据观察到的信息，提出可能的原因假设。一个好的假设应该能解释所有观察到的现象。如果多个假设都能解释现象，优先选择最简单、最直接的那个（奥卡姆剃刀原则）。

3. 验证（Verify）

使用工具对假设进行验证。例如，如果怀疑是内存泄漏，可以用 ASan 或 Valgrind 来验证；如果怀疑是 CPU 热点，可以用 perf 来确认。

bash 复制代码

# 用 ASan 验证内存问题
gcc -fsanitize=address -g -O1 test.c -o test
./test

# 用 perf 验证 CPU 热点
perf record -g ./my_application
perf report

4. 总结（Summarize）

问题解决后，一定要进行总结和复盘：问题的根本原因是什么？当时哪些分析是对的、哪些是弯路？以后遇到类似问题能否更快定位？这些总结才是真正的"经验"积累。

一个实际案例

让我用一个实际案例来说明这套方法论的应用：

现象：某嵌入式设备在运行 72 小时后，主进程被 OOM Killer 杀掉。

观察：查看 dmesg 发现 OOM Killer 选择性杀掉了我们的主进程。查看 /proc/meminfo 发现系统内存已经耗尽。通过 top 观察，发现主进程的内存占用在持续增长。

假设：主进程存在内存泄漏。

验证：使用 ASan 重新编译主进程，启动后发现大量内存泄漏报告，最终定位到一处在错误路径中未释放的 malloc 分配：

c 复制代码

// 泄漏代码示例
char *buf = malloc(BUFFER_SIZE);
if (buf == NULL) {
    return -1;  // 这里没有问题
}
if (init_device() != 0) {
    return -1;  // BUG: 这里没有 free(buf)，内存泄漏！
}
// ... 正常使用 buf
free(buf);
return 0;

修复：在错误处理路径中补充 free(buf)。

总结：对于所有资源申请（malloc、open、socket 等），必须确保每一条错误路径都有对应的释放操作。可以考虑使用 goto cleanup 的模式来统一处理资源释放。

结语

问题排查是一门实践性极强的技能。阅读文章只能获得"知道"，真正的"会"需要在实际项目中不断地练习和积累。我希望这个专栏能成为一个系统性的参考，在你遇到具体问题时提供方向和方法。

在后续的文章中，我会逐一深入每个专题，结合真实案例和可复现的代码示例，把每一个工具和方法讲清楚、讲透彻。

下一篇预告 ：【内存优化】内存优化以及 oom 排查整体思路

欢迎关注专栏，一起交流学习！如有问题请在评论区留言。