相册卡顿的系统级排查复盘：fsync 不要在锁里调用

最近在处理相册批量解密时，遇到了 App 端预览和缩略图加载明显卡顿、响应时好时坏的问题。很多人第一直觉是"解密算法太耗 CPU"，但排查下来，根因却藏在几个极其容易被忽视的系统深水区里：临界区里的慢 IO、fsync 的内核语义，以及后台线程的调度优先级。这里简单复盘一下这三个底层的暗坑。

一、背景：诡异的卡顿

设备上的媒体文件支持加密存储。用户输入安全密码后，后台会启动一个解密线程，遍历存储卡上所有已加密的照片/视频，逐个原地解密。与此同时，App 侧的相册在独立进程里持续工作：刷新列表、解密缩略图、生成预览。两边共享同一套底层解密接口，因此也自然而然地共享了一把互斥锁（下文称 decMutex）。

问题报告是一句很模糊的话："批量解密时，相册响应速度异常，有时点开一张图片要卡好几秒。"

二、第一直觉的破产：卡的根本不是"解密计算"

遇到这种问题，很多人的第一直觉是：几百 MB 的视频解密，CPU 肯定吃不消。但抓下来的性能日志直接否定了这个假设------单张照片解密极快，真正的耗时集中在每个文件结尾的一步：

ini 复制代码

[dec] file=video_0007 decrypt done, compute cost 130 ms
[dec] file=video_0007 fsync cost 8400 ms <-- 耗时黑洞在这里

一个大视频，解密计算只要 130 毫秒，但收尾的 fsync 花了 8 秒！原因也合理：刚写过的文件有大量脏页（Dirty Pages），fsync 必须等内核把它们全部刷到物理存储介质上。到这里，也仅仅是后台解密"慢"，还不至于导致前台 UI"卡"。真正致命的是下一点。

三、扒开应用层的代码，解密收尾的逻辑不出所料，是这种很多开发"闭着眼睛就会写"的灾难级范式：

scss 复制代码

int decryptVideo(const char* path) {

  std::lock_guard<std::mutex> lock(decMutex); // 整个函数无脑持锁

  // ... 逐块解密、回写 ...

  fflush(file);

  fsync(fileno(file)); // 致命点：极度不可控的慢 IO 直接塞进了锁里！

  fclose(file);

  return 0;

}

在这个架构下，后台大视频解密和 App 前台小缩略图解密，抢的是同一把 decMutex。一个完美的"延迟传染链"就此成型：后台线程拿锁 -> 撞上 fsync 陷入长达 8 秒的底层存储 IO 等待 -> 这 8 秒内，前台 UI 线程哪怕只想解密一张几 KB 的缩略图，也会被这把互斥锁死死挡在门外。用户感知到的现象，就是点开图片的瞬间整个相册卡死。

不要把慢 IO 塞进内存锁。

互斥锁（Mutex）的底层语义，是保护极速的"内存状态一致性"，绝不是用来掩护底层物理介质"把数据刷干净"的漫长过程。一旦把不可控的慢 IO（如 fsync、大文件读写、网络同步）塞进持锁临界区，就等于把底层存储的物理延迟，无差别地传染给了整个系统的并发调度链，最终直接让最脆弱的前台 UI 线程买单。

四、被滥用的 fsync：C 库缓冲与内核 Page Cache 的语义边界

很多业务开发一遇到"存数据"，就无脑在关键路径上砸 fsync，连 VFS 的读写边界都没搞清。 fflush(FILE)*：仅将 C 库的用户态 Buffer 推进内核的 Page Cache。得益于 Linux VFS 的读一致性机制，只要数据进了 Page Cache，其他进程（如相册 UI）此时去读，拿到的就已经是最新明文，根本不需要等底层 Block 设备那漫长的 IO 耗时。

fsync(fd)：强制触发 Page Cache 落盘到底层物理介质。它的唯一语义是抗掉电/抗 Kernel Panic。理清底层机制，再看这块极其蹩脚的业务逻辑：要求"解密后相册立刻显示"，依赖的是 VFS 读一致性，一个极速的 fflush 足矣；要求"断电重启后是明文"，才需要 fsync 兜底。

把负责持久化兜底、耗时极长的 fsync，强行塞进要求实时响应的持锁临界区里死等磁盘 IO，这属于典型的用战术上的勤奋制造架构上的灾难。持久化完全应该扔到后台异步做，绝不能在关键锁里卡死流水线。

五、优雅的重构：先 flush，再解锁，最后再 fsync 把临界区收窄到只保护"内存/缓冲一致性"，把昂贵的物理持久化一脚踢到锁外：

scss 复制代码

int decryptVideo(const char* path) {
  std::unique_lock<std::mutex> lock(decMutex); // 改成 unique_lock，便于提前解锁
  // ... 逐块解密、回写 ...

  fflush(file); // 1) 刷到页缓存：此后读到的就是明文，跨进程可见一致性已保证
  lock.unlock(); // 2) 在干"重活"之前提前释放锁，不再阻塞前台！
  fsync(fileno(file)); // 3) 锁外落盘：无论怎么慢，也只拖慢后台自己
  fclose(file);
  return 0;
}

重构后的系统表现：

锁一旦解耦，后台的 fsync 就算被底层 UFS/eMMC 堵上 10 秒，也绝对不会波及 UI 的并发读取。靠着 VFS Page Cache 的读一致性，完美的 IO 延迟隔离就此达成。

另外，重构时我顺手砍掉了原代码在遍历循环末尾的全局 sync()。既然前面已经做了 per-file fsync 保障了逐个文件的原子落盘，最后再来一脚全局 sync 纯属脱裤子放屁。遇到突发掉电，per-file 落盘的界限干干净净，绝不会出现"一半明文一半密文"的系统级脏状态。

除了锁和 IO，在排查中我还挖出了另一颗深水炸弹------调度策略被严重滥用。这个后台解密线程在创建时是这么写的：

ini 复制代码

pthread_attr_setschedpolicy(&attr, SCHED_RR);

param.sched_priority = sched_get_priority_max(SCHED_RR) - 4;

很多应用层开发有一种极其危险的直觉："这批数据很重要，给它个最高优先级让它赶紧跑完"。这是对 Linux 调度器缺乏底线敬畏的表现。SCHED_RR 是实时（RT）调度策略，把一个铺满所有 CPU 核的 CPU+IO 密集型后台任务挂到 RT 队列，等于让它成了抢占前台 UI、预览和视频编码的"霸王龙"。系统在解密时发生剧烈卡顿，这是必然的反噬。

即使把优先级改成 sched_get_priority_min(SCHED_RR) 也是掩耳盗铃，因为 RT 队列的最低优先级，在内核里依然碾压所有普通的 CFS 线程。后台大批量任务的正确归宿只有一个：老老实实滚回 SCHED_OTHER 并调大 nice 值，或者直接丢进 SCHED_BATCH 策略里。

后台任务必须学会克制。在操作系统的视角里，"重要"绝对不等于"紧急"。后台解密慢上几秒，用户毫无感知；但前台抢占导致 UI 掉一帧，就是真真切切的卡顿。

不要把慢 IO 塞进内存锁，分清页缓存与物理落盘的边界，管好线程的实时特权。系统架构的优雅，往往就体现在对系统资源的克制里。