背景
公司的主打产品是一款跨平台的 app，我的部门负责为其提供底层的数据传输 sdk，我负责的是 android 端的 sdk 开发。
SDK 并不直接加载在 App 主进程中，而是隔离在一个单独的进程中，两个进程通过 TCP 连接进行通信。这种做法的目的是减少因 SDK 崩溃导致主进程崩溃，为用户带来更好的体验。
如图所示，SDK 主要实现于 service.so 中，被 Work 进程加载，kernel.so 通过 JNI 嵌入在 App 主进程中，前者作为侦听端，后者为连接端。
然而，这种方式存在一个问题：当侦听端口被占用时，两个进程无法建立通信，导致数据无法传输。为了解决这个问题，我们计划使用本地套接字（Unix Domain Socket）替代 TCP 套接字，因为前者不依赖端口号，只依赖文件路径，而 Android 的私有存储可以有效防止文件冲突。
这个替换过程不能一蹴而就，因为 App 进程加载的 SO 文件与 Work 进程加载的可能不是同一个版本。考虑到向后兼容，新的 service 版本需要同时侦听 TCP 和本地两个通道，新的 kernel 版本也需要同时连接这两个通道，哪个先连接上就使用哪个。
开发完成的自测阶段一切正常，验证了以下组合：
TCP本地, TCPTCP 成功本地本地, TCP本地成功本地, TCPTCPTCP 成功本地, TCP本地, TCP本地, TCP 均成功，一般本地抢先
结果符合预期，提测阶段也顺利通过，于是通过版本灰度，逐渐替换线上的旧版本，各个灰度阶段观察正常，最后正式全量发布。
问题发生
全量发布两天后，正式将特性分支合并入 master，结果合并后不到 30 分钟，QA 反馈主端 OOM（内存溢出）崩溃异常升高，需要回滚版本验证。
了解情况后，发现主端的全部版本崩溃率确实从 0.01% 升高到了 0.05%~0.07% 的水平，且大量新增的崩溃类型堆栈显示 OOM 信息。最关键的是，崩溃升高的趋势与 SDK 灰度的节奏完全吻合，而在这期间主端没有发布新的版本，于是只能回滚 SDK 版本尝试。
糟糕的是刚刚合并的代码，使用 revert 回滚提交的几个 commit 又出现了一大堆冲突提示。在解决冲突的过程中，QA 等不及了，建议从之前合并的位置直接拉分支打版本，一顿操作猛如虎，很快就打好了回滚版本，当天就通过了测试小流量。
第二天一看，崩溃率果然应声下降，于是 QA 开启全量修复。同时研究了一个短平快的 master 回滚方案：新建一个目录，克隆并 checkout 到合并前的代码，将 .git 目录删除后用这个目录覆盖旧的工作目录，最后将所有 modified 的文件作为新版本直接提交。这样做的好处是可以得到与合并前完全相同的代码，防止手工处理冲突引入新的变更。
问题分析
随着回滚版本的放量，主端 OOM 崩溃逐渐回归正常，进一步坐实了新版本存在问题。OOM 问题非常不好排查，原因是崩溃时的堆栈与引入 bug 的地方已经相差了十万八千里，不能直接定位问题点。
好在这个版本之前做过一次小流量，看当时的崩溃率没有明显升高。在准备全量前，合并了 master 上的最新修改、iOS 平台的一些代码等，因此重点排查两个版本的差异部分，应该就可以定位引入问题的点。
走查了一遍，没有发现明显的内存泄漏代码：
master 是稳定版本，不存在内存泄漏；iOS 平台代码通过宏定义作了隔离，对 Android 没有影响；只有一个地方非常可疑——这是一个日志上报操作，只在特定场景下发生，日志上报时并不是直接上报到服务器，而是放入一个队列，再由专门的线程负责上传。一次上报并不会占用太多内存，但关键是一旦进入这个特定场景，日志就会一直产生，而主端会在传输数据的过程中频繁调用这个接口，导致大量的日志进入队列，特别是当用户处于非 WiFi 环境下，日志上报会被关闭来节省流量，进一步加剧了队列积压，最终导致队列疯狂增长耗尽内存……
知道了原因，改起来就简单了，加一个 bool 标记，上报过后设置这个标记下次就不再上报了，因为这类日志有一条用来排查问题就足够了。
问题定位修复版都打好准备送测了，老大的一句话提醒了我——最好能在本地复现一下。于是基于有问题的版本，稍加修改让它一启动就不停上报日志，关闭 WiFi 打开 4G，用这个版本在测试机上跑了一整天，进程居然没崩溃！
于是不得不评估一下日志上报的泄漏规模，按一条日志最大 300 字节、主端 2 次/秒的调用频率计算，一天占用内存为 300 2 3600 * 24 = 51840000 B。
AI建筑知识问答
用人工智能ChatGPT帮你解答所有建筑问题
22 查看详情 
与同事一起研究这个问题后，我又提出了一个疑点：如果是因为日志泄漏导致的 OOM，那应该是 Work 进程崩溃，而不是出现大量的 App 进程崩溃。如果是因为内存耗尽导致系统上所有进程崩溃，那也至少是崩溃率一起升高，而不像现在只有 App 进程崩溃率升高，所以越看越不像是这个原因导致的。
问题根因
正当排查方向一片迷茫的时候，同事的一句话提醒了我——如果能抓到崩溃现场的日志就好办了。可是怎么抓呢？崩溃平台记录的是崩溃时间和 CUID，后者用于标识一次唯一的崩溃事件；日志抓取需要时间范围和用户 UID，而崩溃平台并不提供 UID。
这时同事神秘兮兮地祭出了一条链接，点开一看：ID-Mapping，可以将各种系统的 ID 进行批量转换，其中就包括 CUID 向 UID 的转换，好家伙，这不就是我想要的？老同事真的浑身都是宝，摸着他们过河错不了~
大部分 UID 没有捞取到日志，只有两个用户有日志。内容非常多但都是重复的，看起来 Work 进程没有启动，导致连接端一直在进行重连。在连接后期都发现了这样的日志：
2021-10-30T20:55:19.84255454 [b61e7920] {netio} LocalHandler::post_connect: local endpoint failed with system:24, fatal error2021-10-30T20:55:19.84408116 [b61e7920] {netio} kernel_message_transmit:handle_io: pipeerror|system:24 type=1|channel=12021-10-30T20:55:19.84480116 [b61e7920] {netio} kernel_message_transmit:handle_io: pipeerror|system:24 type=1|channel=22021-10-30T20:55:31.05991064 [b61e7920] {netio} kernel_service_interface:on_ready_timeout: restart! running=1, channel=0
查了下系统错误码：
#define EMFILE 24 /* Too many open files */
这种错误一般是打开的句柄超过 Linux 进程的最大打开文件句柄数（一般是 1024），这个值对于服务器程序来说一般是不够用的，需要通过系统设置来拉高上限。但对于 App 进程是足够了，怎么会超限呢？难道是出现了句柄泄漏。于是马上去走查了连接关闭的代码：
if channel='local' then close local_channelelse if channel='tcp' then close tcp_channelelse nothing channel = 'none'
这里使用了伪代码来说明大意，其中 channel 标记当前使用的连接方式，初始时设置为 none，连接时两种方式同时发送异步连接请求，先收到应答的连接将设置对应的 channel 值并关闭另一种连接通道，连接建立成功后 channel 必为两种方式之一（local | tcp）。
上面推演的是正常的场景，当 Work 进程没有启动而导致两个通道都无法完成连接时，channel 将一直保持 none 值直到超时，在连接重启前，会尝试使用上面这段代码清理资源，此时就会命中最后的 else 逻辑——什么也不做——从而导致连接句柄被泄漏。以 10 秒重连、6 秒超时一次计算，每 16 秒就泄漏 2 个句柄，1024 个句柄泄漏光只需要不到 2 小时！
为了验证，专门修改了一版代码，人为制造 Work 进程不启动的场景，果然跑了没多久 App 进程就崩溃重启了。确定了问题根因，再回顾一下现象，之前那几个疑问就能得到解释了：
问题表现为打开文件、创建线程均失败的 OOM 问题，实际是 OOF（Out of FD），句柄泄漏的表现和内存泄漏有相似的地方。问题存在于 kernel，当 kernel 耗光句柄后对应的 App 进程会因 EMFILE 错误崩溃，Work 进程反而是没什么事，所以表现为 App 进程崩溃率单独升高。只影响一部分 Work 进程长时间不启动的用户，这部分用户占比较少，所以崩溃率升高有限。之前小流量的那版也有问题，只是放量较少所以崩溃率升高不明显而已。
问题的修复非常简单，就是在关闭清理资源时，不再根据 channel 判断，直接 close 所有句柄。打好的修复版本在 Work 进程不启动的场景下运行了一天也没有出现崩溃，对外灰度后，观察 App 崩溃率正常，逐步全量覆盖线上版本，最后合并入 master。
结语
复盘整个 OOM 问题产生的过程，为何在灰度阶段没有发现 App 进程崩溃率异常升高呢？原来在看崩溃数据时是过滤了 SDK 版本号的，而实际发生异常升高的版本号却是奇特的 0.0.0.1 版本，因而没有观察到。
为何 OOM 问题会集中在 0.0.0.1 版本中？进一步排查发现并非只有 OOM 崩溃是这样，90% 的崩溃都归类在了这个版本下面，原因竟然是 App 在初始化时没有处理好先后关系，从 SDK 拿版本号时 SDK 还未初始化，所以得到了一个无效的版本值。更严重的是，该问题几乎一直存在，而我们之前过滤版本号的做法几乎可以肯定是不正确的，想到这里不由得背上直冒冷汗！幸好有这次问题的复盘，不然这个问题要继续存在多久还是个未知数~
最后总结一下 OOM 问题的处理方法：
首先不要心慌，特别是在不经求证的情况下靠猜测来定位问题、靠不断发小版本在线上验证问题，这样做一来不严谨，二来效率比较低，最终很可能还会定位不到问题；最好的办法是通过现场日志来定位出错的场景，可以极大的缩小排查范围；OOM 与 OOF 在 Java 崩溃堆栈中有相似的表现，因此遇到这类问题可以多考虑下句柄泄漏的可能性，而不是一味观察内存的分配与释放；如果认定是内存泄漏，那么从代码层面预估的泄漏规模一定要有符合常识，特别是能制造泄漏场景复现问题。
另外可能还有人对 Work 进程为何没有启动感兴趣，但这就属于另外一个问题了，可以单独写篇文章了。目前仍在排查中，真的是应了那句：生命不息，debug 不止~~
参考[1]. Git 如何优雅地回退代码，用 reset 还是 revert？
以上就是记一次 android 线上 oom 问题的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/471894.html
微信扫一扫 
支付宝扫一扫 
