分配器对比与跨平台内存管理分析

0. 概述与方法论

本文是一组围绕"移动端内存管理"的源码级分析，全部基于在真实越狱 iPhone 上的实测 + 官方开源仓库逐行核对。核心方法：

• 实测在设备上跑真实汇编：链接 XNU 的 WKdm arm64 汇编直接运行，而非用公共 libcompression 库——测的是设备真实压缩器。
• 交叉编译三方分配器为 arm64 静态库（je_/mi_ 前缀，不覆盖 libc），与原生 libmalloc 跑同等工作负载，每后端独立 fork() 子进程隔离 RSS。
• 源码级溯源：每个结论附带文件名+行号引用（file.c:NNN），不只靠记忆。
• 假设被数据证伪也照实写（见 §6 鸿蒙、§1 的 shared_churn）——bench 的价值正在于它能推翻先入之见。

1. 分配器实测对比（libmalloc / jemalloc / mimalloc）

1.1 测试方法与配置依据

8 个工作负载覆盖：快路径延迟（pair_32b/4kb/1mb）、驻留（hold_20k）、大块（large_1mb）、realloc 增长、线程争用（threaded_4t）、跨线程对象流（shared_churn_6t）。配置依据对齐移动端真实默认：

1.2 实测结果（hold_20k：live≈170MB）

1.3 shared_churn_6t：验证假设·证伪

原假设：跨线程对象流动（A 分配的块 B 释放）会触发同核争用+跨核 cache 弹跳，libmalloc 的 per-CPU 杂志锁局部性优势应显现、缩小与 jemalloc 的 gap。workload：6 线程共享 2048 槽池，每线程 malloc(64)+atomic_exchange(slots[i],new)+free(old)。

每线程速率：libmalloc 1.58M ops/t（跌 7.2×）、jemalloc 10.0M ops/t（跌 4.8×）——libmalloc 跌得更狠，假设被证伪。

根因（源码级）：① libmalloc 每操作付两把杂志锁（malloc 的 SZONE_MAGAZINE_PTR_LOCK+free 的锁，libmalloc/magazine_tiny.c:2409/506）叠加争用的 atomic_exchange；② jemalloc 跨线程 free 免费——je_free 对小对象总进当前线程 tcache（不追踪分配者），无 remote-free 惩罚，快路径仍无锁（jemalloc/include/jemalloc/internal/cache_bin.h:348），只付 atomic 争用。→ per-CPU 锁局部性真实但不足以抵消"两次锁/次"的固定开销；jemalloc per-thread 无锁 tcache 在所有吞吐场景都赢。

1.4 scudo：安全优先的加固分配器

scudo（LLVM Sanitizer Combined Allocator successor）是 Android 11+ 的默认分配器，设计目标是安全加固而非极致速度。上游 scudo standalone 只有 linux.cpp/fuchsia.cpp/trusty.cpp 三个平台层，没有 Darwin 端口。本次测试写了完整的 Darwin 平台层（darwin.cpp：用 os_unfair_lock 替代 Linux futex、arc4random_buf 替代 getrandom syscall、mach_task_basic_info 替代 /proc/self/statm），是首个在真实 iOS 设备上跑的 scudo benchmark。

1.5 libmalloc vs scudo 安全性源码级对比

两者都有安全加固，但加固的对象和层次完全不同。

libmalloc 的安全模型：保护元数据 + 信任平台沙箱

libmalloc 的加固哲学："保护 free list 不被腐败，其余交给平台沙箱"。

① free list 指针校验和——两条路径（magazine_inline.h:190-253）：

• arm64e（A12+，含 A14）路径：用 ARMv8.3 PAC（Pointer Authentication Code）对 free list 指针做硬件签名——ptrauth_sign_unauthenticated(ptr, ptrauth_key_process_dependent_data, ...)。签名密钥是 process-dependent 的（每进程不同），攻击者无法伪造。解签失败直接 __builtin_trap()。对"篡改 free list 指针"这个具体威胁，比 scudo 的 CRC32 更强——PAC 是密码学签名，CRC32 可碰撞。
• 非 arm64e 路径：free_list_gen_checksum 做 3 轮折叠（64→32→16→8 bit）只留 4 bit，碰撞概率 1/16 = 6.25%——非常弱。

② 没有 UAF 检测：free → 直接链入 free list → 立即可复用。没有 quarantine、没有 State 追踪。UAF 在复用窗口内被静默吞掉。

③ 没有 double-free 检测：第二次 free 只是把指针再链入（如果 checksum 过了）。没有 State 字段说"这个块已经是 Available 了"。

scudo 的安全模型：每块全生命周期追踪

scudo 的加固哲学："每个 chunk 从分配到释放到回收都有 header 追踪 + CRC32 校验 + quarantine 延迟"。

① 每 chunk header 有 State + CRC32（chunk.h:62-73）：8 字节 header 含 ClassId(8bit)/State(2bit)/Origin(2bit)/Size(20bit)/Offset(16bit)/Checksum(16bit)。每次操作都校验——loadHeader 重算 checksum 对比，不符即 reportHeaderCorruption。16-bit CRC32 碰撞 1/65536。

② quarantine——UAF 检测的核心（combined.h:1128-1141）：free 不直接回收，State 从 Allocated→Quarantined。进 QuarantineCache 延迟释放。quarantine 窗口内 UAF 访问 → 下次 drain 回收时 header 被腐败 → checksum 不匹配 → 报错。这是 libmalloc 完全没有的机制。

③ MTE——100% 硬件级 UAF 检测（memtag.h:30，combined.h:1158）：在 MTE 硬件上，free 时 setRandomTag 换标签。UAF 用旧 tag 访问 → CPU tag check 硬件 trap（SIGSEGV），100% 检测率。libmalloc 不支持 MTE（A14 未实现 MTE）。

④ GWP-ASan——概率性保护页采样（combined.h:29-33）：编译时开 GWP_ASAN_HOOKS，抽样分配放 guard page 区域，overflow/underflow 直接 SIGSEGV 并附栈追踪。libmalloc 没有；WebKit 有独立的 bmalloc 做类似的事。

1.6 为什么 iOS 不用 scudo 替代 libmalloc

scudo 确实比 libmalloc 快（60 vs 88 ns），安全机制也更全。但"快+安全"不是 iOS 不换 scudo 的原因——libmalloc 有 4 件 scudo 架构层面做不到的事，其中第 1 件是 iOS 流畅性的命根。

① jetsam 协同链（命根——scudo 完全没有）

这是 iOS App 后台能保命的核心。libmalloc 把"何时还内存"的决策权下放给内核，scudo 架构里没有这个通道：

关键反证：把 libmalloc 换成 scudo → App 后台时 scudo 不响应 jetsam 压力信号 → jetsam 看到占着 RAM 不还 → 直接杀进程。这是 iOS 不能接受的结果——流畅性的第一支柱"进程还在"就塌了。

② arm64e PAC 比 scudo CRC32 更强（对 free list 篡改这个具体威胁）

scudo 的 16-bit CRC 可碰撞；libmalloc arm64e 用 ptrauth_sign 硬件密码学签名。对 free list 篡改这一个威胁，iOS 已有比 scudo 更强的方案。scudo 多出的 quarantine/MTE/GWP-ASan 防的是 UAF/overflow——这些在 iOS 上由代码签名 + 沙箱 + WebKit bmalloc 在平台层消化了。

③ per-CPU 杂志——固定核数硬件的最优 cache 局部性

Apple 既造 SoC（A14=6 核）又出 OS，已知固定核数。per-CPU 杂志的锁 cache line 永远只被同一核碰——不跨核弹跳。scudo 的 per-thread TSD（pthread_key_create）每次访问多一层 pthread_getspecific，线程多时 tcache 膨胀。

④ 25 年深度集成

libmalloc 是 Bertrand Serlet 1999 年设计（magazine_malloc.c:26），25 年来与 XNU/CoreFoundation/Foundation/UIKit 深度耦合：malloc_zone_t 注册机制、scalable_zone_info_task 跨任务安全读（诊断/Instruments 基础）、malloc_memory_event_handler 注册在 dispatch 源上（事件总线）。scudo 没有这些 Darwin 集成。

2. 源码级对比：libmalloc vs jemalloc

2.1 快路径定位：per-CPU vs per-thread（核心差异）

libmalloc：杂志按当前 CPU 选，不是按线程。libmalloc/magazine_rack.c:228：

unsigned int rack_get_thread_index(rack_t *rack) {
    index = _malloc_cpu_number();        // 当前 CPU 号，不是线程号
}
// magazine_tiny.c:2399  tiny_malloc_should_clear
mag_index = rack_get_thread_index(rack) % rack->num_magazines;

杂志数 = 核数：num_magazines = mag_max_magazines()（magazine_malloc.c:1699，注释"per-CPU magazines that scale way better"）。

jemalloc：tcache 按线程绑，经 tsd（thread-specific data）。

Apple 为何选 per-CPU：① 核数已知且小（A14=6），杂志数恒定省内存（线程多时 jemalloc tcache 膨胀）；② 杂志锁的 cache line 永远只被同一核拿→不跨核弹跳（锁真正开销在跨核 cache line 迁移，per-CPU 避开了）；③ 杂志元数据硬件 cache 局部性钉在核上；④ 同核争用在 iOS cooperative 调度下低频。

2.2 快路径是否持锁：持锁 vs 无锁（~88ns vs ~21ns 根因）

libmalloc：快路径仍持 magazine 锁，即使命中单槽 cache：magazine_tiny.c:2409

SZONE_MAGAZINE_PTR_LOCK(tiny_mag_ptr);        // ← 加锁
ptr = tiny_mag_ptr->mag_last_free;           // 唯一一个 cache 槽
if (mag_last_free_msize == msize) {
    SZONE_MAGAZINE_PTR_UNLOCK(tiny_mag_ptr); // 命中也锁了
    return ptr;
}

jemalloc：无锁无原子，走线程私有栈：cache_bin.h:348

void *ret = *bin->stack_head;     // 线程私有栈，无 lock/atomic
if (likely(low_bits != bin->low_bits_low_water)) {
    bin->stack_head = new_head;
    *success = true; return ret;
}

libmalloc 的快 cache 仅 mag_last_free 单槽；jemalloc 是深栈（每 size-class 几百个）。libmalloc 每操作还付 free 的校验和（free_list_checksum_ptr，抗堆攻击）。→ 88ns 里大头是：锁开销(~30-40ns)+校验和(~10-15ns)+链表慢路径(~15-20ns)。

2.3 回收策略：pressure 驱动 vs decay 定时

libmalloc：region 进 depot 后才逐页 MADV_FREE_REUSABLE（magazine_tiny.c:839，pinned_to_depot 保证锁外 madvise 安全）。回收是 pressure/recirc 驱动；大块走 MADV_REUSABLE death-row cache。

jemalloc：decay_dirty/decay_muzzy（默认 10s，jemalloc/src/pac.c:78）→ purge：MADV_FREE(→muzzy)/MADV_DONTNEED(decommit)。定时、可调、可确定。

→ 解释实测 retained：libmalloc 17MB（pressure 下 depot madvise 起作用）、jemalloc 默认 81MB（10s decay 没触发）、jemalloc0 6MB（decay=0 立即 decommit）。

3. libmalloc 设计思想与 jetsam 协同链

3.1 设计思想

源码文件头注释（magazine_malloc.c:26）：Author Bertrand Serlet, August 1999; 2008 多线程增强"in the spirit of Hoard"（Emery Berger ASPLOS 2000 的 per-processor heap）。libmalloc 是 Hoard 在 Apple 硬件上的特化，四个核心思想：

1. per-CPU 杂志而非 per-thread：Apple 既造 SoC 又出 OS，已知固定核数。在固定小核数硬件上缓存局部性最优、无 false sharing，无需为任意线程数动态建/毁 tcache。
2. RAM 是瓶颈而非 CPU：4-6GB 手机上 retained → 被 jetsam 杀 → App 死。回收与内核压力信号耦合（reactive），而非 jemalloc 定时 decay（"eventually 还"在突发压力下来不及）。把"何时还内存"决策权交给内核——它知道全局压力。
3. 安全优先：手机跑不可信 Web 内容（WebKit），堆加固比纳秒更重要 → 校验和指针 + guard page。
4. 原生集成：用 Darwin 独有的 VM-tag / MADV_FREE_REUSABLE / vm_purgable_control——这是 mmap-only 的 jemalloc/mimalloc 拿不到的协同通道。

3.2 jetsam 协同链（双层：主动提示 + 被动释放）

A. 主动提示层（常开——让内核优先回收 libmalloc 的页，而非杀进程）

1. VM tag：每次 mach_vm_allocate(... VM_MAKE_TAG(VM_MEMORY_MALLOC_TINY))（libmalloc/vm.c:89）。jetsam 杀选启发式按 per-task VM tag 找大消耗者。
2. MADV_FREE_REUSABLE（CONFIG_MADVISE_STYLE）：depot 中 free span 走 MADV_FREE_REUSABLE（vm.c:463，注释 :467 确认）。Darwin 语义：标记页可复用 → 内核压力下优先回收这些页，先于杀进程。libmalloc 的"已释放但缓存"页是全系统最便宜的 RAM 回收源。
3. Large death-row（large_entry_cache）：大块 free → LIFO 进缓存 + MADV_REUSABLE；内核可回收，下次大块 alloc 直接复用。
4. Purgeable（vm_purgable_control(VM_PURGABLE_SET_STATE)）：可清除分配 → 内核单方面清空。

B. 被动释放层（收到压力信号即 flush）——完整调用链

内核 kern_memorystatus(jetsam) 监控压力，越阈值
   → 投递 NOTE_MEMORYSTATUS kqueue 事件(带 NORMAL/WARN/CRITICAL 级别)
   → 用户态 dispatch source DISPATCH_SOURCE_TYPE_MEMORYSTATUS 触发
   → libmalloc: malloc_memory_event_handler(event)            [malloc.c:3139]
       event & MALLOC_MEMORYSTATUS_MASK_PRESSURE_RELIEF
       → malloc_zone_pressure_relief(0, 0)                    [malloc.c:3142]
           → 每个 zone->pressure_relief(zone, 0)              [malloc.c:3181]
               → 杂志区: szone_pressure_relief                  [magazine_malloc.c:1425]
                   ① tiny/small/medium_madvise_pressure_relief [magazine_tiny.c:976]
                      遍历每 per-CPU 杂志每 region，RACK_DISPOSE_DELAY
                      → 迁 depot → 对每个 free span MADV_FREE_REUSABLE
                   ② Large death-row: 锁外拷出后逐个 mvm_deallocate_pages(全 munmap)
                      置 flotsam_enabled=FALSE 使压力期新大块 free 不再回缓存

净效果：jetsam 发压力信号后毫秒级内，libmalloc 把所有 free/cached 页归还内核 → jetsam 的回收轮拿走 RAM 而无需杀进程。

C. 可观测层（供 jetsam/diagnostics 安全读他任务 zone）

scalable_zone_info_task(task, memory_reader_t reader, ...)（magazine_malloc.c:954）：跨任务（用 memory_reader_t）安全读 malloc zone 统计。

4. 为什么 libmalloc 慢但 iOS 流畅

bench 证 libmalloc 慢 4-6×，但手里的 iPhone 依然丝滑。因为分配器快路径延迟根本不是流畅性的瓶颈——流畅性是一个系统级指标，由完全不同的因素决定。

4.1 绝对量级：不是瓶颈

libmalloc 一次 32B malloc+free = ~88ns。一个 App 每帧（16.6ms@60Hz）做 10 万次 alloc/free（已是很重的逻辑）：100,000 × 88ns = 8.8ms < 16.6ms，不掉帧。jemalloc 同负载省下的 6.7ms 在 16.6ms 帧预算里省不出肉眼可感区别。

4.2 流畅性真正依赖的 5 件事，libmalloc 全做对了

1. 内存不膨胀 → 不被 jetsam 杀（最关键）：libmalloc retained 低（17MB）+ jetsam 协同，App 后台能保命、前台不重启。jemalloc 默认（81MB）同压力下更早被杀 → 切回前台冷启动 → 真正可感的卡顿。流畅的前提是"进程还在"。
2. UI 在独立高优先级线程，不与 App 逻辑争 malloc：iOS 渲染是 Core Animation + Render Server（独立进程 backboardd），App 只提交 layer 树。App malloc 慢只影响逻辑线程，Render Server 不用 App 的 malloc → 渲染帧率不受影响。
3. UIKit 用对象池/缓存，规避了快路径：UICollectionView/TableView 的 cell 复用、UIImage 缓存——高频 UI 对象根本不走 malloc/free 循环，一次 dequeue 是查表不是分配。
4. ARC + autorelease pool 的释放是批量的：ARC 释放延迟批量（autoreleasepool drain 一次性 free），不是紧耦合 alloc/free pair。libmalloc 的单槽 cache 在批量复用时命中率高。bench 的 pair_32b 是最不利于 libmalloc 命中率的模式——真实 App 没这么用。
5. A14 算力冗余 + 大核突发：Firestorm 大核 ~3GHz，88ns ≈ 260 周期，微秒级抖动被算力冗余吃掉。UI 线程最高优先级 + 大核绑定。

4.3 对照：Android 用 jemalloc 但仍卡？

Android Bionic 用 jemalloc（后换 Scudo），分配器更快。但 Android 卡顿来源是：后台进程多→RAM 竞争→LMK 频繁杀→切回冷启动；ART GC 停顿；RenderThread 与 App 共进程争用。Android 选择了快的分配器，输在了"内存/进程保命"。这反向印证：分配器快慢不是关键，内存策略协同才是。libmalloc 慢但协同好，iOS 反而更流畅。

5. 内核 WKdm 多线程解压

5.1 源码结论：解压多 CPU 并发，压缩单线程

5.2 实测（A14 / 6 核，每线程独立 dst+scratch 模拟 per-CPU）

TYPICAL 6 核聚合解压 ~8000 MiB/s ≈ 4× 单核——内核真实聚合解压能力。未达理想 6× 因内存带宽/缓存争用。压缩为单线程，~1600 MiB/s 即设备上限，故 bench 单线程压缩有代表性；解压单线程低估内核（已补 6 核并发测）。

6. 鸿蒙 NEXT 对比：统一渲染 + memcg/zswapd

6.1 统一渲染：渲染耦合从"iOS 略优"改为"持平"

统一渲染把"栅格化"从 App 进程搬到 RS 进程——结构上向 iOS 的 backboardd 靠拢。App UI 线程卡顿不再直接卡栅格化，和 iOS"App 卡了当帧仍能渲染"同一机理。渲染耦合维度：撤销原"iOS 略优"，改判持平。

6.2 内存保命：从"iOS 胜（鸿蒙靠 LMK 粗放杀）"改为"结构持平"

核实 OpenHarmony kernel v6.1 的 mm/ 目录，发现一整套 Huawei 自研、非 mainline 的内存子系统：

关键发现：① drivers/staging/android/lowmemorykiller.c 在该分支不存在——OH 不带传统 in-kernel LMK；② memcg_reclaim.c 头注释 (c) 2020-2022 Huawei，引用 hyperhold_inf.h——OH 有个叫 HyperHold 的内存子系统；③ zswapd 的 ub_zram2ufs_ratio/ub_ufs2zram_ratio 是分层压缩交换：冷页先压到 zram（压缩 RAM，快）→ 不够再换到 UFS（闪存），与 iOS"vm_compressor 压 RAM → 极端压力 swap 到闪存"是同一分层策略。

6.3 剩余真实差距（精细化）

鸿蒙 = "Linux memcg 的细粒度 cgroup 定向回收 + iOS 式系统级压缩"的混合。iOS 干脆没用 cgroup，走 per-task+全局压缩+优先级带这条更简的路。三者 reclaim→compress→kill 都到位，但分工哲学不同：Linux 重在"组内精细定向"，iOS 重在"全局压缩最冷+按 App 重要性杀+分配器主动还"，鸿蒙两者都要。

鸿蒙若卡，卡在哪（修正版）：① GC 停顿（ArkTS，头号嫌疑，iOS 无）；② 声明式 diff+复杂 list（AOT 缓解但结构性在）；③ 中低端芯片算力不足放大以上。不再大概率卡在"被杀冷启动"（鸿蒙已有分层回收）。若鸿蒙想追平 iOS 流畅性下限，该补的不是分配器（二阶项），而是继续把 ArkTS GC 往接近无感调。

7. iOS 的 memcg 对等物：per-task ledger + phys_footprint

iOS 没有 memcg（cgroups 子系统），但有完整功能对等物，且架构与 Linux memcg 在关键点上不同。XNU kern_memorystatus.c（5355 行）源码级核实：

7.1 iOS 的"memcg 对等物"组件

7.2 与 Linux memcg 的 5 点架构差异

① 记账指标：phys_footprint vs RSS+swap（iOS 更聪明）

Linux memcg 记账 RSS+swap+cache，可压缩的匿名页按原大小全额计入。iOS phys_footprint 把页拆成 internal_pages（未压缩）+ internal_compressed_pages（已压缩）分别记——压缩后 footprint 变小，App 看起来更省。iOS 的记账天然激励"压缩回收"：压缩后 footprint 降、不触限；Linux memcg 除非开 zswap 记账否则激励不同。

② 分组单元：per-task vs cgroup

Linux memcg = 任意 cgroup 树，可多进程归一组共享预算、可嵌套、父子传播（灵活但 page_cgroup 每页挂钩开销大）。iOS = per-task（进程），Darwin 每任务天生有独立 vm_map，页天然归一 task，无需挂钩，再加优先级带归类。无"多进程共享预算"原生抽象，粒度粗但简单、零挂钩开销。

③ 限制：active/inactive 双限 vs 单 limit（iOS 为移动端调优）

Linux memcg：一个 memory.limit_in_bytes，超限触发回收。iOS：per-task 有 memlimit_active（前台）+ memlimit_inactive（后台）两套限（:973），加 FATAL/NONFATAL 标志（fatal=超限杀，nonfatal=只回收不杀）。前台 App 给大限、后台小限、自动切换——移动端专用调优，Linux 要靠 cgroup 切换+多 limit 模拟。

④ 回收：系统级压缩 vs per-cgroup LRU（最根本架构差）

Linux memcg 回收是 per-cgroup 定向——try_to_free_mem_cgroup_pages() 回收这个 cgroup 的 LRU。iOS 回收是 系统级压缩 + per-task 压力事件双轨：内核 vm_compressor 压缩全系统最冷页（不挑哪个 task，挑最冷），同时给被压 task 发 memorystatus 压力事件 → 该 task 的 libmalloc malloc_memory_event_handler 跑 pressure_relief → 主动 MADV_FREE_REUSABLE 自己的可回收页。iOS 把回收责任部分下放给分配器（libmalloc 主动提示），Linux memcg 模型里分配器只被动被回收——这是 iOS 一个真实但较小的精细度优势。

⑤ 杀：全局按优先级带 vs per-cgroup OOM

Linux memcg：cgroup 超 fatal 限 → 该 cgroup 内 OOM killer 杀一个。iOS：系统压力到阈值 → jetsam 按全系统优先级带从低到高杀（IDLE → AGING_BAND → ... → 前台最后），max_kill_priority（:909）控制杀到哪一带为止。iOS 杀是全局 App 优先级驱动（前台几乎不可能被杀，后台 IDLE 先死），Linux 是组内 OOM，与 App 重要性无关。

9. 背景：Darwin 与 XNU 内核是什么

本文反复提到"Darwin""XNU""Mach""BSD"——这里统一解释。

Darwin 是 Apple 所有操作系统（macOS / iOS / iPadOS / watchOS / tvOS / visionOS）的开源内核 + 核心用户态。它是盖在 GUI 之下的那一层操作系统底座：

┌─────────────────────────────────────┐
│  UIKit / SpringBoard (iOS 的触控 UI) │  ← iOS 专属层
│  AppKit / Aqua   (Mac 的桌面 UI)     │  ← macOS 专属层
├─────────────────────────────────────┤
│  Darwin   ← 就是这一层               │
│  ├─ XNU 内核 (Mach + BSD + IOKit)    │
│  ├─ libSystem (libc / libmalloc…)    │
│  └─ launchd / 核心守护进程            │
├─────────────────────────────────────┤
│  硬件 (A14 / M1 / M2 …)              │
└─────────────────────────────────────┘

• macOS = Darwin + AppKit/Aqua（桌面 UI + Mac 框架）
• iOS = Darwin + UIKit/SpringBoard（触控 UI + 移动框架）
• watchOS / tvOS = Darwin + 各自 UI 层

Darwin 是共同的根。iPhone 和 Mac 跑的是同一个内核家族，只是上层 UI 不同——这就是为什么越狱 iPhone 能跑很多 Mac 的命令行工具（uname、sysctl、mach_vm_allocate 都是同一套）。本文测试设备 Darwin 20.6.0 = iOS 14.8（对应 macOS 11 Big Sur 内核版本号）。

9.1 XNU 内核 = Mach + BSD + I/O Kit

Darwin 的内核叫 XNU（"X is Not Unix"，递归缩写），是一个混合内核，三部分粘在一起跑在同一个内核地址空间：

不是学术意义的微内核——Mach 没有跑在用户态，而是与 BSD 共享内核地址空间，是混合内核。

9.2 本文源码的归属

9.3 为什么 scudo 需要"Darwin 移植"

scudo 上游只有三个平台层：linux.cpp（Linux futex、getrandom、/proc/self/statm）、fuchsia.cpp、trusty.cpp。没有 Darwin 版——因为 Android/Fuchsia 不跑在 Darwin 上，Google 不会写。Darwin 的 API 跟 Linux 不同：

所以"Darwin 移植"= 把这些 Linux 特有调用换成 Darwin 等价物。这不是优化，是让 scudo 能在 XNU 内核上编译运行的基础工作。本项目写了 darwin.cpp + DarwinConfig，是首个在真实 iOS 设备上跑的 scudo benchmark。

9.4 开源

Apple 在 github.com/apple-oss-distributions 开源了 Darwin 的内核（XNU）和核心库（libmalloc、Libc、libdispatch 等）。这就是能拉到 xnu-7195.141.2 和 libmalloc-521.120.7 源码逐行核对的原因。但 GUI 层（AppKit/UIKit/Aqua）不开源。Darwin 是开源的；macOS/iOS 是闭源的商业产品 = Darwin + 闭源 GUI 框架。

10. 结论与方法论

1. iOS libmalloc 慢 4-6× 但 iOS 流畅——因为它的优化目标不在 bench 能测的"分配速度"，而在"内存保命（jetsam 协同）+ 安全加固 + 固定核数可预测"。per-CPU 杂志 + MADV_FREE_REUSABLE + pressure_relief 让 App 后台能保命。
2. jemalloc0（decay=0）速度最快且内存最省 → 综合最优（速度 21ns、retained 6MB）。decay 调参是 jemalloc 的免费午餐。mimalloc 调参反而是坏调参（不降 RSS 还拖垮大块）。
3. per-CPU 杂志的锁局部性优势真实但不足以抵消"每操作两次锁"的固定开销——shared_churn 证伪了"跨线程流让 libmalloc 追平"的假设，gap 反从 4.2× 拉到 6.3×。jemalloc per-thread 无锁 tcache 在所有吞吐场景都赢。
4. scudo（Android 11+ 默认）是"安全优先"的中间件：比 libmalloc 快 31%（60 vs 88 ns），比 jemalloc 慢 2.9×（60 vs 21 ns）。retained 最高（206MB）。大块瓶颈（8298 ns，secondary cache max=512KB 绕过缓存）。其 quarantine+checksum+MTE+GWP-ASan 是针对 Android 威胁模型的安全防线——iOS 不需要（沙箱+代码签名+libmalloc PAC+bmalloc），Android 需要（恶意应用+不可信 NDK）。不同威胁模型决定不同分配器选择。
5. iOS 不用 scudo 替代 libmalloc——不是 scudo 不好，而是 libmalloc 有 4 件 scudo 架构层面做不到的事：jetsam 协同链（MADV_FREE_REUSABLE + pressure_relief 回调 + VM tag——scudo 只有 MADV_DONTNEED + 定时 decay，不响应内核压力信号，换上去 App 会被 jetsam 杀）、arm64e PAC（对 free list 篡改比 scudo CRC32 更强）、per-CPU 杂志（固定核数最优）、25 年深度集成。让 scudo 做 Darwin 协同 = 重写 libmalloc。两套方案是各自生态的局部最优。
6. 鸿蒙 NEXT 在"渲染耦合"和"内存保命"两个一阶维度已结构性追平 iOS（统一渲染 + memcg/zswapd 分层回收），不再是"粗放 LMK 杀进程"。剩余 iOS 真实优势收窄为：无 GC（vs ArkTS GC）+ 算力统一冗余 + 分配器级主动回收提示。鸿蒙该补的是 ArkTS GC 而非分配器。
7. iOS 没有 memcg，但 per-task ledger+phys_footprint+memlimit(active/inactive)+jetsam 带+vm_compressor 是其功能对等物，且在"压缩页分开记账""active/inactive 双限""全局压缩+分配器主动还""按 App 优先级杀"这几点上比 Linux memcg 更为移动端调过。三者 reclaim→compress→kill 都到位，分工哲学不同。

方法论自省

• 源码优先：每个结论带文件名+行号，不只靠记忆。尤其"鸿蒙靠 LMK 粗放杀"这种基于旧认知的判断，必须用源码核实——否则停在错误叙事上。
• 假设被证伪也照实写：shared_churn 推翻了"per-CPU 在跨线程流会追平"的假设，鸿蒙核实推翻了"靠 LMK 粗放杀"的判断。bench 的价值正在于它能推翻先入之见。
• 区分一阶项与二阶项：分配器速度是二阶项，内存保命/有无 GC/渲染是否进程外是一阶项。优化错了维度（如鸿蒙继续优化分配器而非 GC）事倍功半。
• 诚实边界：对 ArkUI 运行时/ArkTS GC 等无源码逐行核对的判断均标出不确定，等待进一步核实。