操作系统进阶

Android 应用跑在 Linux 之上,面试里的 OS 题不是纯书本题:进程、线程、协程会落到主线程/线程池/协程调度;虚拟内存、mmap、page fault 会落到 Binder、文件映射和启动性能;epoll 会落到 Looper 与网络连接。

一、进程、线程、协程的进阶对比

维度	进程	线程	协程
资源边界	独立虚拟地址空间	共享进程地址空间	运行在线程上
调度者	Linux 内核	Linux 内核	Kotlin/运行时协作调度
切换开销	高,涉及地址空间等上下文	中,保存寄存器/栈等	低,挂起恢复状态机
Android 例子	App 进程、WebView 多进程、remote service	UI 线程、RenderThread、OkHttp Dispatcher	`suspend`、Flow、ViewModelScope

虚拟内存让每个进程看到连续独立地址空间,由页表映射到物理页。Android 中它直接影响大文件读取、so 加载、Dex/OAT 映射、Binder 缓冲区等。

进程虚拟地址
  ↓ 页表 / MMU / TLB
物理内存页
  ↑
缺页(page fault)时由内核把文件页/匿名页调入内存

mmap:把文件或设备映射到进程虚拟地址,按需加载,减少显式 read/copy;Binder 驱动也利用 mmap 建立用户态可访问缓冲区。
page fault:访问的虚拟页尚未在物理内存中,CPU 触发异常进入内核处理。轻微缺页可能只建映射,重大缺页可能要读磁盘。
启动性能关联:冷启动读取 dex、resources、so 时可能产生大量缺页;Baseline Profile、预加载和减少冷路径大文件访问都能降低抖动。
内存压力关联:匿名页、文件页、Ashmem/共享内存都会参与系统回收;低端机上大 Bitmap 和大 mmap 文件都要考虑峰值。

Linux 把文件、socket、pipe、eventfd 等都抽象成文件描述符(fd)。Android 的网络、数据库、日志、Looper 唤醒都离不开 fd。

I/O 机制	特点	Android 关联
阻塞 I/O	调用线程等待结果	主线程网络/磁盘会 ANR
非阻塞 I/O	没数据立即返回	需要轮询或事件通知
select/poll	监听多个 fd,但扩展性一般	传统多路复用方案
epoll	事件驱动,适合大量 fd	Looper、网络框架、native event loop

Looper 为什么不忙等? MessageQueue 没消息时,底层通过 epoll_wait 阻塞等待 fd 事件或超时;有消息、Binder、输入事件、定时器到期时再被唤醒。这也是“死循环不等于耗 CPU”的经典追问。

fd 常见问题:

Linux 普通任务主要由 CFS 调度,目标是公平分配 CPU;Android 在此基础上叠加进程优先级、线程 nice 值、cgroup/cpuset、前后台策略。

死锁四条件:互斥、持有并等待、不可剥夺、循环等待。Android 中常见死锁并不只来自 synchronized,还来自主线程等待后台、后台反向切主线程、Binder 同步调用互等。

Thread-A: 持有 dbLock → 等待 networkLock
Thread-B: 持有 networkLock → 等待 dbLock
结果:循环等待,两边都无法推进

实践建议:

Q1:进程、线程、协程怎么区分? 进程是资源隔离单位,线程是内核调度单位,协程是用户态/运行时的异步抽象。协程挂起不阻塞线程,但执行仍要占用线程,因此阻塞操作放错调度器仍会影响性能。

Q2:mmap 和普通 read 有什么区别? read 把数据从内核缓冲复制到用户缓冲,mmap 把文件映射到虚拟地址空间,访问时按页加载,可减少拷贝和简化随机访问。但 mmap 仍可能触发 page fault,不是“免费加载”。

Q3:Looper 底层为什么用 epoll? Looper 要同时等待消息队列、输入、Binder/管道等 fd 事件。epoll 能高效等待多个 fd,无事件时阻塞让出 CPU,有事件再唤醒,避免忙等。

Q4:Android 死锁如何排查和避免? 看线程堆栈确认谁持有什么锁、谁在等待;避免嵌套锁顺序不一致、持锁做耗时操作、主线程同步等待后台。必要时用超时、锁顺序规范和异步化拆环。