[原创]从时间片轮转到调用级并发：unidbg 单后端多线程架构重构-Android安全-看雪安全社区

# 从时间片轮转到调用级并发：unidbg 单后端多线程架构重构

> 本文讨论的是 unidbg 在单 Unicorn 后端下模拟多线程 native 程序时的通用架构问题。文中的命令、线程、回调与返回值均为抽象示例，不对应任何具体应用、接口或业务数据。

本文是前文[《给 unidbg 装上原生时间片：如何让模拟器真正跑起多线程》](https://bbs.kanxue.com/thread-291862.htm)的后续。

## 摘要

第一版多线程方案，也就是先前的那篇文章，解决了一个最直观的问题：让主任务和 native worker 能够按原生时间片轮流执行。它把 unidbg 从依赖 syscall、JNI 回调等偶然 safe point 的协作式调度，推进到了可被指令预算稳定打断的抢占式轮转模型。

但是，“线程能够轮流执行”并不等于“多个 native 调用能够安全重叠”。当两个 Java 宿主线程向同一个 Unicorn backend 提交命令时，系统还必须回答一组更困难的问题：当前是谁在驾驶 backend？新调用如何请求通行权？旧调用暂停后由谁恢复？返回值和终态属于哪一代调用？一个调用释放 JNI local reference 时，会不会清掉另一个暂停调用仍在使用的对象？

第二版方案开始引入 backend owner、handoff、command result 和超时终态，但仍然保留了大量全局槽位和按命令号匹配的兼容逻辑。它能处理部分交接，却不能从结构上保证调用身份、运行上下文、JNI 引用和终态的一致性。

最终方案不再把“任务”作为唯一调度单位，而是在任务之上增加一层 invocation-owned runtime：每次 native 调用都拥有独立的 record、generation、submitter、carrier、immutable context、terminal 和 JNI reference scope。backend 仍然只有一个，但调用可以通过 FIFO 申请、在真实 safe point 交接、暂停和显式恢复。

可以把整个演进理解成一座单车道桥：

- 第一版给桥装上红绿灯，让车辆能够轮流前进；
- 第二版增加了临时交警，但通行记录仍写在几块共享白板上；
- 最终版给每辆车发放独立通行证、流水号、货单和回执，并规定只有真正取得桥权的车辆，其上下文才对桥上的设施可见。

项目地址：<a href="elink@856K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6E0P5s2W2G2L8#2u0Q4x3V1k6#2L8X3W2V1j5X3N6Q4x3X3c8E0N6h3I4@1K9i4c8Z5M7X3g2S2k6r3W2F1k6H3`.`."><mark class="encrypted">5dbK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6E0P5s2W2G2L8#2u0Q4x3V1k6#2L8X3W2V1j5X3N6Q4x3X3c8E0N6h3I4@1K9i4c8Z5M7X3g2S2k6r3W2F1k6H3`.`.</mark></a>

---

## 一、第一版时间片方案的缺陷

第一版方案的核心是 native timeslice：C 后端在执行一定数量的 guest 指令后主动停止，Java 调度器保存当前任务上下文，再从可运行队列中选择下一个任务。

这层设计是必要的。没有可预测的 native safe point，worker 能否获得执行机会只能依赖 syscall、hook 和回调返回，调度器只能不断猜测“什么时候适合切线程”。时间片让停止变成了 backend 的明确能力。

但第一版解决的是“车能不能轮流开”，并没有建立调用级交通规则。

第一版的完整执行链可以概括为：

![图片描述](upload/attach/202607/1072248_H22B2SMUY2R85ZZ.webp)

这张图里的主语始终是 `Task`。它能说明“下一个运行谁”，却无法说明“这次 native 调用是谁、它的结果最终交给谁”。这正是后续重构需要补上的一层。

### 1.1 第一版不是“做错了”，而是验收目标太窄

回头看第一版，最容易产生的误解是：既然后来又做了架构重构，那么 native timeslice 一定是失败的。事实恰好相反——时间片本身完成了它被设计出来时的目标。

第一版已经能够验证以下能力：

- C 后端可以按照 guest 指令预算主动停止，而不是只能等 syscall、hook 或函数返回；
- Java 层能够区分“自然返回”和“时间片耗尽”这两类停止原因；
- Task 被打断后，寄存器、栈和程序计数器能够保存，并在下一次调度时恢复；
- 多个 `RUNNABLE` Task 可以轮流取得 backend；
- `FUTEX_WAIT` 能让任务离开可运行队列，对应的唤醒又能让它重新入队；
- worker 不只是被创建出来，而是真的能够获得时间片并执行 guest 指令。

这些验证共同证明了一件重要的事：**单 backend 上的 native 协作式抢占已经成立。**

问题在于，我们当时把这个结论向前多推了一步：

```text
已经证明：多个 Task 可以被打断、保存、恢复和轮转
错误外推：多个重叠 native invocation 因此一定能正确完成
```

这两句话看起来只差半步，实际上跨过了一条架构边界。`Task` 是调度对象，回答“下一刻让谁运行”；`Invocation` 是调用对象，回答“谁发起、谁拥有、谁等待、谁接收结果、谁负责清理”。时间片只解决了前一个问题。

如果把单 backend 比作一座一次只能通过一辆车的窄桥，第一版做成的是红绿灯系统：灯会按时变色，车辆也确实能够交替前进。但“能轮流上桥”不代表整套运输系统已经完备，因为我们还没有为每一趟运输建立独立车牌、货单、收件人和签收回执。

所以，第一版“不对”的准确含义不是时间片算法错误，而是：**它通过的是 Task 轮转验收，却被拿去承担 Invocation 正确性。验收标准比真实并发语义窄了一层。**

### 1.2 问题是怎样被发现的：worker 在运行，carrier 却不能自然返回

真正推动第二次重构的，不是某一处代码看起来不够优雅，而是一组无法用“线程没有跑起来”解释的运行现象。

一次 native 调用进入调度器后，可以把承载其入口和最终返回的主任务称为 **carrier**，把它依赖的其他 guest 任务称为 **worker**。最初的怀疑很自然：carrier 长时间没有返回，是不是 worker 根本没有创建、没有入队，或者一直没拿到 backend？

被动观测很快排除了这种简单解释：

- worker 已经完成创建并进入任务表；
- worker 的状态确实从等待转为可运行；
- 调度日志中能看到 worker 被选中并取得 backend；
- worker 的程序计数器和上下文持续变化，说明它不是“空调度”；
- 常见的等待与唤醒路径已经发生，不能把问题概括为漏掉一次普通 WAKE。

换句话说，桥上的红绿灯在工作，辅助车辆也确实开上了桥。可是 carrier 仍可能长期停留在这样的状态：

```text
carrier.state = RUNNABLE
carrier.waitAddress = 0
carrier.finished = false
observation = expired
```

这四个条件同时出现非常关键：

- `RUNNABLE` 表示 carrier 并未睡死；
- `waitAddress = 0` 表示它当时不在一个可直接归因的 futex 等待点；
- `finished = false` 表示 guest 函数还没有自然走到返回边界；
- `observation = expired` 表示宿主的等待窗口先结束了。

如果只看最终的 timeout，很容易得到“native 卡死”的结论；如果把任务状态、实际派发和 wall time 放在一起看，则会发现另一种可能：**调用不是不可返回，而是在单 backend 的共享调度窗口中，还没获得足够且连续的推进机会，宿主就先取消了观察。**

这也是第一版第一次暴露出模型裂缝的地方。Task 状态都可以是“合法的”，调度器也可以持续工作，但调用整体仍然没有一个能够被准确描述的生命周期。

### 1.3 如何逐层排除看似合理的解释

发现“worker 已运行、carrier 未完成”以后，不能立刻把原因归结为 timeout，更不能直接把 timeout 调大。我们按照因果位置逐层排除了几类解释。

#### 排除一：不是 worker 没有创建，也不是队列完全失效

任务创建记录、可运行状态变化、实际 dispatch 以及上下文前进共同证明，worker 已经进入了调度闭环。若 worker 从未运行，修复方向应当是线程创建或队列；但证据表明问题发生在这些步骤之后。

#### 排除二：不能让 carrier 独占 backend

另一个直觉方案是提高 carrier 优先级，甚至只调度 carrier，期待它尽快返回。受控验证显示，carrier 会走到一个真实的依赖等待点：它需要某个 worker 更新共享状态或释放同步条件才能继续。

这说明 carrier 和 worker 不是“主任务与噪声”的关系，而是协作关系。只让 carrier 上桥，就像让货车独占桥面，却把负责开闸的工程车永远挡在桥外；货车得到再多绿灯，也只能停在关闭的闸门前。

因此，问题不能通过“把所有时间都给 carrier”解决。正确目标不是单方面提高优先级，而是在保持协作推进的同时，准确计算每一次调用的等待与完成。

#### 排除三：队列调序和强制唤醒只能改变表象

我们还验证过几类常见调度补丁的思路：提高某类任务的选中概率、改变队列顺序、强制把任务改成可运行、在退出前增加 drain window，或者在观察即将到期时再多跑若干轮。

这些措施可能改变某一次运行的路径，甚至让失败出现得更早或更晚，但它们无法建立稳定的因果闭环：

```text
如果任务本来就在 RUNNABLE，强制 wake 没有增加新信息；
如果 carrier 依赖 worker，永久优先 carrier 反而会破坏协作；
如果完成权没有归属，调整队列也不能保证结果交给正确调用；
如果 wall timeout 的含义错误，增加 drain 只是延后同一个问题。
```

一个补丁只有在回答“它修复了因果链的哪一层”时才是架构修复。仅仅让某次运行通过，不足以证明队列顺序或某个额外唤醒就是根因。

#### 排除四：不是缺少一个神奇的 timeout 数字

被动记账揭示了最容易被忽视的一点：第一版的 deadline 是全局 wall deadline。它从宿主进入调度循环时开始计时，期间不只计算 carrier，还计算全部 worker、任务切换、hook、日志和 Java 调度开销。

因此，在一个看起来很长的观察窗口里，carrier 实际得到的 backend 执行份额可能只占一小部分。宿主时钟已经走完，并不等于 carrier 真正执行了同等时长。

一次受控验证中，放宽全局 wall cutoff 后，原本被判定超时的 carrier 能够继续推进并自然返回。这证明了一个必要事实：**旧 deadline 确实可能杀死一个本来可返回的调用。**

但这仍不意味着“把固定时间改大”就是最终答案。换一组任务组合或调度顺序后，同一个固定额度仍可能失效。于是结论进一步收窄：

```text
不是旧数值太小；
也不是新数值还不够大；
而是用所有 Task 共享的 wall time，表达某一次 Invocation 的生命周期，本身就不成立。
```

这一区分很重要。延长 timeout 是参数修补；把提交等待、backend 占用、协作调度和调用终态分别建模，才是语义修复。

### 1.4 真正暴露出来的问题：Task 调度正确，不等于 Invocation 正确

把上述证据合在一起，可以得到比“调度偶尔超时”更准确的结论：

| 观测事实 | 能证明什么 | 不能证明什么 |
|---|---|---|
| worker 被创建、入队并实际执行 | Task 调度闭环已经工作 | 调用一定能完成 |
| carrier 仍为 `RUNNABLE` | carrier 不是简单睡死 | 它已经获得足够执行机会 |
| 常规 wait/wake 路径发生 | 基础同步事件可被处理 | 所有调用生命周期都被正确建模 |
| 放宽 wall cutoff 后能够自然返回 | 旧 deadline 会过早终止可返回调用 | 某个更大的固定数值永远正确 |
| carrier 独占时反而进入依赖等待 | worker 是必要协作者 | 提高 carrier 优先级可以替代并发语义 |

第一版真正缺少的，是位于 Java 提交者与 native Task 之间的调用实体。没有这个实体，系统无法可靠回答：

- 当前 carrier 属于哪一次提交；
- 同一个入口连续出现时，前后两代调用如何区分；
- 哪个调用有资格把自己的上下文发布给 backend；
- 某个结果、异常或 timeout 应该交给哪个等待者；
- 调用被暂停后，它创建的 JNI local reference 应由谁保管；
- backend stop 是一次交通让路，还是调用真正结束；
- 观察者停止等待时，guest 调用究竟已经终止，还是仍可继续推进。

桥梁系统的故障至此才算被准确描述：红绿灯没有坏，车辆也不是完全不动；缺的是每趟运输的身份与所有权。没有车牌，两辆同型号车会混淆；没有独立货单，后车可能覆盖前车的货物记录；没有准确回执，桥中央的一次临时停车也可能被误报成“已经送达”；所有车辆共用一个倒计时，则某辆车还没真正开多久，就可能因为别的车占桥而被判超时。

后面四个缺陷，正是这个总问题在代码中的具体表现：调度单位只有 Task、预算使用全局 wall time、交通状态与调用终态混淆，以及 JNI local reference 仍采用 VM-wide 生命周期。

### 1.5 调度单位只有 Task，没有 Invocation

第一版调度器认识的是 `Task`：

```text
main task
worker task #1
worker task #2
scheduled function task
```

每个任务具有 `RUNNABLE`、`WAITING`、`FINISHED` 等状态，调度器按照时间片和 futex 状态轮转任务。

但是一次 Java 调用和一个 Task 并不总是一一对应：

- 同一个命令可能被连续调用多次；
- 同一个宿主线程可能提交多个 generation；
- 一个调用的 carrier 暂停期间，另一个调用可能进入 backend；
- worker 可能是某次调用的间接依赖，却不是调用结果的拥有者；
- carrier 的生命周期可能长于 Java 方法的一次等待窗口。

如果系统只有 Task，没有 Invocation，就无法精确表达：

```text
这个 scheduled task 属于哪一次调用？
这个 TIMEOUT 是当前 generation 的，还是上一轮残留的？
这个 worker fault 应该交给哪个 submitter？
同一个 command 再次出现时，能否覆盖旧结果？
```

第一版常见的做法是以 command number 或当前 active command 作为关联键。这在严格串行时看起来可用，一旦允许重叠就会产生歧义。

桥梁比喻中，这相当于调度器能识别“卡车”“轿车”，却没有车牌和通行证。两辆同型号车辆先后上桥，收费站只能看到它们都叫 `command-X`，无法判断回执应该交给谁。

### 1.6 一个全局 wall timeout 同时计算了所有人的时间

第一版通常以一次调度循环的 wall clock 作为命令预算：

```java
long start = System.currentTimeMillis();

while (hasRunnableTask()) {
    Task task = pickNextTask();
    task.dispatch(emulator);

if (System.currentTimeMillis() - start >= timeoutMillis) {
        return null;
    }
}
```

这段逻辑简单，但它混合了至少四类时间：

- command carrier 自己实际执行的时间；
- 依赖 worker 消耗的时间；
- 无关 background task 消耗的时间；
- Java 调度器、日志、hook 和上下文切换消耗的时间。

在真机上，多个线程能够并发运行；在单 backend 中，它们必须串行分享同一段 wall time。如果把总 wall time 直接当成 carrier 的生命周期预算，就可能出现如下情况：

```text
命令总窗口：8 秒
carrier 实际获得 backend：1.2 秒
worker 与框架开销：6.8 秒
结果：carrier 被判 TIMEOUT
```

从宿主视角看已经过去 8 秒，从 carrier 视角看它可能刚执行了一小部分。于是 timeout 不再表达 native 生命周期，只表达“所有任务共同消耗了多少宿主时间”。

简单增大 timeout 也不能成为可靠修复，因为不同运行中的 worker 数量、等待路径和共享状态演化不同。某次运行在更大窗口内自然返回，并不能证明某个固定数值就是正确的 native 生命周期。

### 1.7 停车、让路和到达终点被混为一谈

时间片方案增加了多种 backend 停止原因：

```java
enum BackendStopReason {
    NORMAL,
    TIMESLICE,
    EMU_STOP,
    FAULT
}
```

这解决了“`emu_start()` 为什么返回”的问题，但上层很容易错误地把“backend 已停止”理解成“native 命令已完成”。

实际上：

- `TIMESLICE`：当前任务只是用完了本轮时间片；
- `EMU_STOP`：另一个线程要求 backend 回到 Java safe point；
- `FUTEX_WAIT`：任务暂时不可运行；
- `NORMAL` 或真实 guest `RET`：才可能代表自然返回；
- `FAULT`：执行失败；
- host observation 到期：只代表观察被取消。

一辆车在桥中央被红灯拦停，不等于它已经抵达终点。`EMU_STOP` 应该触发保存现场和交接，而不是生成一个“已完成”的业务回执。

### 1.8 VM-wide JNI local reference 无法支持暂停调用

传统顺序 JNI 调用常用一个 VM 级 local-reference map：

```java
private final Map<Integer, ObjRef> localObjectMap = new HashMap<>();

void deleteLocalRefs() {
    for (ObjRef ref : localObjectMap.values()) {
        ref.obj.onDeleteRef();
    }
    localObjectMap.clear();
}
```

顺序执行时，这个模型没有问题：调用开始时加入参数对象，调用结束时统一清理。

重叠调用下会出现严重污染：

```text
调用 A：把 Object[] 参数加入 localObjectMap
调用 A：在 safe point 暂停
调用 B：把自己的参数加入同一个 localObjectMap
调用 B：完成并调用 deleteLocalRefs()
调用 A：恢复执行
调用 A：通过原 handle 读取 Object[]，得到 null
```

这种错误很隐蔽，因为它最终可能表现为 JNI 空指针、数组访问失败，甚至被兼容路径包装成普通数值返回。表面看像业务参数错误，根因却是 local reference 的生命周期仍停留在单调用时代。

---

## 二、第二版命令服务方案的缺陷

第二版在时间片调度之上增加了 command service：引入 backend owner、handoff、显式 result、watchdog 和 command terminal。相比第一版，它已经意识到“谁在驾驶 backend”和“命令是否完成”是两个独立问题。

但这一版仍处于从 task-centric 向 invocation-centric 过渡的中间态。许多正确概念被放进了全局字段、单槽 Map 和日志字符串中，因此能够处理单次交接，却难以保证重叠调用的严格隔离。

### 2.1 Backend owner 有了，但调用所有权仍然分散

第二版通常会增加类似字段：

```java
private Thread backendOwnerThread;
private CommandResult lastCommandResult;
private CommandResult commandTerminalResult;
private Map<Integer, CommandResult> terminalByCommand;
private Task pendingFaultTask;
private CommandResult pendingFaultResult;
```

这些字段分别解决某一个局部问题：

- owner thread 防止多个宿主线程同时驾驶 backend；
- last result 让 caller 能看到最近一次终态；
- terminal map 让 watchdog 发布 TIMEOUT；
- pending fault 让 safe point 消费 backend exception。

问题在于它们没有被同一个 invocation 对象统一拥有。一次调用的身份散落在：

```text
当前 task
当前 command number
当前 submitter thread
某个 generation 字段
全局 last result
某个 keyed terminal map
日志 detail 中的 cmd=...
```

当同一 command 发生第二次调用时，旧 terminal、旧 watchdog 或旧 fault 可能覆盖新调用。代码不得不增加越来越多的判断：

```java
if (result.getDetail().contains("cmd=" + cmd)) {
    // 假定结果属于当前命令
}
```

这类字符串匹配只能作为 legacy fallback，不能作为并发所有权模型。

### 2.2 `Map<Command, Result>` 无法表达同命令多代调用

第二版常见的数据结构是：

```java
Map<Integer, CommandRecord> recordsByCommand;
Map<Integer, CommandResult> terminalsByCommand;
```

它隐含了一个假设：同一 command 同时最多只有一条记录。

现实中可能出现：

```text
command-X / generation 7 / submitter A
command-X / generation 8 / submitter A
command-X / generation 9 / submitter B
```

如果新 record 覆盖旧 record，会产生三类问题：

1. 旧 watchdog 到期，把 TIMEOUT 写进新调用；
2. 新调用 natural return，被旧 submitter 消费；
3. fault 只能按 command 匹配，无法确定属于哪个 carrier。

即使把 value 改成 `List<Record>`，如果消费时仍只传 command，也无法解决歧义。真正的索引必须包含 carrier identity、generation 和 original submitter。

### 2.3 reserve 与 bind 分两步，暴露中间竞态

为了在 carrier 创建前预留 generation，第二版可能采用：

```text
reserve invocation
create scheduled carrier
bind invocation to carrier
```

顺序调用时没有问题，并发 caller 会看到一个危险窗口：reservation 已进入 FIFO，但 carrier 尚未绑定。此时另一个线程也可能 reserve、bind 或取消，导致 FIFO head 与真实 carrier 关系不稳定。

如果 command、context、generation 和 carrier 不是在同一把 dispatcher 锁内建立，就不能保证：

```text
context.command == record.command == carrier.command
```

第二版虽然有 reservation 概念，但还没有把 atomic create-and-bind 作为生产路径的不变量。

### 2.4 运行上下文仍依赖全局 active fields

许多 native stub、JNI router 或环境模拟逻辑需要知道当前执行的 command、origin 和 detail。第二版往往通过全局字段或 System property 暴露：

```java
activeCommand = nextCommand;
activeOrigin = nextOrigin;
System.setProperty("runtime.command", String.valueOf(nextCommand));
```

问题是 caller 创建了 B，不等于 B 已经取得 backend admission。A 可能仍在 guest 中运行。如果 B 在提交时就写全局字段，A 的 JNI stub 会突然读到 B 的上下文。

ThreadLocal 也不是完整答案，因为 guest task、backend owner 和 Java submitter 不一定运行在同一个宿主线程上。运行上下文必须绑定 logical admission，而不是绑定“最近一次谁写了变量”。

### 2.5 返回值与终态仍可能来自两条路径

第二版虽然定义了 `CommandResult`，但 caller 仍可能这样工作：

```java
CommandResult before = dispatcher.getLastCommandResult();
Number value = callNative(...);
CommandResult after = dispatcher.getLastCommandResult();

CommandResult result = after != before ? after : null;
```

这里的 `value` 来自一次 native 调用，`result` 来自全局槽位。重叠时二者可能不属于同一 generation。

真正的 exact outcome 必须是一个不可拆分的整体：

```text
value
+ terminal
+ command
+ generation
+ original submitter
```

任何一项无法匹配，都不应构造成功 outcome。

### 2.6 异常可能被兼容路径包装成“成功返回 -1”

传统兼容路径经常在 native exception 后返回 `-1`：

```java
catch (RuntimeException e) {
    log.warn("native call failed", e);
    return -1;
}
```

随后 scheduled task 看到一个非空 `Number`，可能把它记录为：

```text
COMPLETED value=-1
```

这样 caller 会认为命令自然完成，只是返回了一个特殊数值。对 tracked invocation 而言，这是错误的终态传播。异常必须成为该 invocation 自己的 `FAULT`，不能借用 legacy 数值返回通道。

---

## 三、最终方案：Invocation-Owned Runtime

最终重构不再继续增加全局 gate、优先级或 timeout 例外，而是改变系统的核心抽象：

> Task 负责“代码在哪里继续执行”，Invocation 负责“这次调用是谁、拥有什么、最终结果交给谁”。

### 3.1 六条架构不变量

最终方案以六条不变量为设计起点。

#### 不变量一：同一时刻只有一个 backend 驾驶者

Unicorn backend 不是可重入服务。任何时刻只有一个 owner 可以调用 `emu_start()` 或继续 guest 执行。其他 submitter 必须通过 handoff 请求获得 logical admission。

#### 不变量二：每次调用都有独立身份

调用身份至少由以下字段构成：

```text
carrier task identity
command
generation
original submitter thread identity
```

command number 只是业务类别，不是调用身份。

#### 不变量三：运行上下文只属于 ADMITTED invocation

创建、绑定或排队都不能让 context 对 guest runtime 可见。只有取得 logical admission 的 invocation 才能投影 context；暂停和终态必须立即撤销。

#### 不变量四：value 与 terminal 必须同源

exact outcome 只能由 record 自己保存的 terminal 构造。不得从全局 last-result 补 identity，也不得把 caller 看到的 value 和另一个槽位的 terminal 拼起来。

#### 不变量五：JNI local reference 跟随 invocation 生命周期

每次 tracked 调用拥有独立 local-reference scope。scope 只有在 carrier 已退役且 caller 已解析 outcome 后才释放。

#### 不变量六：非终态永远不能伪装成终态

`PARKED`、`YIELDED`、`BACKEND_STOP` 和 `HANDOFF_REQUIRED` 都是交通状态，不是 command terminal。TIMEOUT、FAULT、CANCELLED 也不能被转换为 COMPLETED。

### 3.2 三层模型

最终架构可以拆成三层。

```text
调用层 Invocation
  command / generation / submitter / context / terminal / refs
                  ↓
桥权层 Admission & Capability
  FIFO request / exact safe point / suspend / resume / owner session
                  ↓
任务层 Task Scheduler
  timeslice / context save-restore / futex / flat round-robin
```

三层的职责必须严格分离：

- Task scheduler 不猜业务 command；
- Invocation 不直接改变 FUTEX 或 picker；
- Capability 只管理 backend 驾驶权，不制造业务完成；
- Context projection 不参与 terminal 决策；
- Reference scope 不决定调度顺序。

最终方案的三层关系如下：

![图片描述](upload/attach/202607/1072248_9YHDBC9FAWWT3UW.webp)

最下层仍然保留第一版文章中的 native timeslice 和 Task 调度器；最终版不是推翻第一版，而是在它之上补齐调用所有权和生命周期。

### 3.3 通行证模型

用桥和车的比喻，可以把主要对象映射如下：

| 架构对象 | 比喻 | 职责 |
|---|---|---|
| Native timeslice | 红绿灯 | 定期让车辆停到安全位置 |
| Backend capability | 桥梁驾驶权 | 保证同一时刻只有一个执行者 |
| CommandInvocationRecord | 独立通行证 | 记录车辆身份、状态和回执 |
| Generation | 通行证流水号 | 区分同一 command 的多次调用 |
| Handoff FIFO | 桥头排队车道 | 防止后来的请求插队 |
| HandoffYield | 交警签发的让行凭证 | 证明旧 owner 在哪个 safe point 让路 |
| CommandInvocationContext | 车辆货单 | 只在车辆真正上桥时可见 |
| CommandInvocationOutcome | 出桥回执 | value 与 terminal 的不可拆分结果 |
| InvocationReferenceScope | 独立行李舱 | 隔离 JNI local references |

---

## 四、具体代码实现

这一章按照代码落点说明最终方案如何实现。示例保留核心逻辑，省略日志、兼容分支和非关键参数。

### 4.1 用强类型结果分离终态与交通状态

首先要避免一个枚举同时表达“命令是否结束”和“为什么暂停”。最终结果模型把 `State` 与 `Kind` 分开：

```java
public final class CommandResult {

public enum State {
        COMPLETED,
        FAULT,
        TIMEOUT,
        CANCELLED,
        NON_TERMINAL
    }

public enum Kind {
        VALUE,
        NULL_VALUE,
        FAULT,
        TIMEOUT,
        OPERATION_CANCELLED,
        PARKED,
        YIELDED,
        BACKEND_STOP,
        HANDOFF_REQUIRED
    }

private final State state;
    private final Kind kind;
    private final Number value;
    private final CommandOwnership ownership;
}
```

`State` 回答“是否已经形成 command terminal”，`Kind` 回答“具体发生了什么”。

```java
public boolean isCommandTerminal() {
    return state == State.COMPLETED
            || state == State.FAULT
            || state == State.TIMEOUT
            || state == State.CANCELLED;
}

public boolean isYielded() {
    return state == State.NON_TERMINAL && kind == Kind.YIELDED;
}
```

这个拆分非常重要。若把 `BACKEND_STOP` 放进 completed 状态，handoff 会被错误地包装成自然返回；若把 `CANCELLED` 当 TIMEOUT，则一次宿主观察结束会被误写成 guest 生命周期失败。

### 4.2 CommandOwnership：结果必须携带调用身份

```java
public static final class CommandOwnership {
    private final int command;
    private final long generation;
    private final long submitterThreadId;
    private final String submitterThread;
}
```

结果匹配不能只比较 command：

```java
public boolean isForInvocation(
        int command,
        long generation,
        long submitterThreadId) {

return ownership != null
            && ownership.command == command
            && ownership.generation == generation
            && ownership.submitterThreadId == submitterThreadId;
}
```

这样即使两个调用使用相同 command，也不会串槽。

### 4.3 CommandInvocationRecord：一次调用的一等对象

最终 record 聚合一次调用的全部关键身份：

```java
public final class CommandInvocationRecord {

public enum State {
        RESERVED,
        BOUND,
        ADMITTED,
        SUSPENDED,
        TERMINAL,
        CANCELLED
    }

private final int command;
    private final long generation;
    private final Thread submitterThread;
    private final String origin;
    private final CommandInvocationContext context;
    private final CommandInvocationReferenceScope referenceScope;
    private final long deadlineMillis;

private volatile Task carrier;
    private volatile CommandResult terminalResult;
    private volatile State state;
}
```

为什么这些字段必须在一个对象里？因为它们的生命周期一致：

- record 创建时确定 generation 和 submitter；
- bind 时确定 carrier；
- admit 时 context 可见；
- terminal 时结果锁定；
- carrier retirement 与 outcome acknowledgement 共同关闭 reference scope。

如果把它们拆进多个全局 Map，系统只能靠约定维持一致，很难形成可验证的不变量。

### 4.4 Context 与 command 在构造阶段强制一致

```java
CommandInvocationRecord(
        int command,
        Task carrier,
        Thread submitterThread,
        CommandInvocationContext context,
        long generation) {

if (context.getCommand() != command) {
        throw new IllegalArgumentException(
                "context command does not match invocation command");
    }

this.command = command;
    this.carrier = carrier;
    this.submitterThread = submitterThread;
    this.context = context;
    this.generation = generation;
    this.state = carrier == null ? State.RESERVED : State.BOUND;
}
```

carrier 创建后还要检查 guest argument 中的 command：

```java
Integer carrierCommand = scheduledCommandArg(task);

if (!Integer.valueOf(command).equals(carrierCommand)) {
    throw new IllegalArgumentException(
            "carrier command does not match invocation command");
}
```

最终建立三个相等关系：

```text
context.command
    == record.command
    == carrier command argument
```

错误在进入 backend 前失败，比运行几秒后再从异常日志猜 command 污染可靠得多。

### 4.5 原子 create-and-bind 消除 reservation 窗口

对于已能创建 carrier 的 active mailbox 路径，不再先 reserve 再 bind，而是在 dispatcher 同一把锁中完成：

```java
public CommandInvocationRecord createBoundCommandInvocation(
        int command,
        CommandInvocationContext context,
        Task carrier,
        long deadlineMillis,
        CommandInvocationReferenceScope referenceScope) {

validateCommandContextAndCarrier(command, context, carrier);

synchronized (this) {
        if (recordsByCarrier.containsKey(carrier)) {
            throw new IllegalStateException(
                    "carrier already has a command invocation");
        }

CommandInvocationRecord record =
                new CommandInvocationRecord(
                        command,
                        carrier,
                        Thread.currentThread(),
                        context,
                        ++invocationGeneration,
                        referenceScope);

recordsByCarrier.put(carrier, record);
        recordsByCommand
                .computeIfAbsent(command, ignored -> new ArrayList<>())
                .add(record);

notifyAll();
        return record;
    }
}
```

这里 carrier identity 是权威索引：

```java
private final Map<Task, CommandInvocationRecord> recordsByCarrier =
        new IdentityHashMap<>();

private final Map<Integer, List<CommandInvocationRecord>> recordsByCommand =
        new HashMap<>();
```

`recordsByCommand` 只负责查询候选集合，不再假设一个 command 只有一个 record。真正完成、fault 和 terminal 消费优先按 carrier 找到精确 record。

### 4.6 Handoff 请求使用 FIFO，而不是全局布尔 flag

```java
private final Deque<CommandInvocationRecord> handoffRequests =
        new ArrayDeque<>();

public boolean requestCommandHandoff(
        CommandInvocationRecord invocation,
        String operation) {

synchronized (this) {
        if (invocation.getSubmitterThread() != Thread.currentThread()) {
            return false;
        }

if (!invocation.requestHandoff(
                operation, ++handoffRequestSequence)) {
            return false;
        }

handoffRequests.addLast(invocation);
        notifyAll();
        return true;
    }
}
```

只有 FIFO head 可以 admitted：

```java
public boolean admitCommandHandoff(
        CommandInvocationRecord invocation) {

synchronized (this) {
        if (admittedInvocation != null) {
            return false;
        }
        if (handoffRequests.peekFirst() != invocation) {
            return false;
        }
        if (!invocation.admitHandoffRequest()) {
            return false;
        }

handoffRequests.removeFirst();
        admittedInvocation = invocation;
        contextProjection.activate(invocation.getContext());
        notifyAll();
        return true;
    }
}
```

FIFO 解决的是 logical admission 顺序，不等同于 Task 调度器的 round-robin。一个 invocation 一旦 admitted，普通时间片轮转不会释放它的调用级身份。

### 4.7 用 HandoffYield 锁定真实 safe point

仅仅收到 `EMU_STOP` 还不够。系统必须证明：旧 owner 在当前 owner session 的某个真实 safe point 保存了现场，并同意让路。

```java
public static final class HandoffYield {
    private final Task ownerTask;
    private final long ownerSessionGeneration;
    private final long safePointSequence;
    private final String operation;
    private final CommandResult result;
}
```

记录凭证时进行精确检查：

```java
synchronized boolean recordHandoffYield(
        Thread requester,
        Task requesterCarrier,
        Task ownerTask,
        long ownerSessionGeneration,
        long safePointSequence,
        CommandResult result) {

if (requester != submitterThread) {
        return false;
    }
    if (requesterCarrier != carrier) {
        return false;
    }
    if (!result.isYielded()) {
        return false;
    }
    if (!result.isForInvocation(
            command, generation, submitterThread.getId())) {
        return false;
    }

handoffYield = new HandoffYield(
            ownerTask,
            ownerSessionGeneration,
            safePointSequence,
            operation,
            result);
    return true;
}
```

在真正 suspend A 时，再次校验 owner session 和 safe-point sequence：

```java
if (yield.getOwnerSessionGeneration() != session.generation) {
    return false;
}

if (yield.getSafePointSequence() != session.safePointSequence) {
    return false;
}

contextProjection.deactivate(admitted.getContext());
admitted.suspendAdmission();
admittedInvocation = null;
```

这防止旧 handoff 凭证在新的 owner session 中被重复使用。

### 4.8 Backend stop 只用于回到 Java safe point

新 requester 只有在以下条件同时成立时才请求 `emu_stop()`：

- requester 是 FIFO head；
- 当前 backend 有 foreign owner；
- 当前 owner 本身属于一个 admitted invocation；
- 同一个 owner 尚未被本 requester 请求过 stop。

```java
if (handoffRequests.peekFirst() == invocation
        && admittedInvocation != null
        && admittedInvocation.getSubmitterThread() == owner
        && owner != stopRequestedForOwner) {

emulator.getBackend().emu_stop();
    stopRequestedForOwner = owner;
}
```

`emu_stop()` 返回不生成 COMPLETED。它只促使 owner 的 `emu_start()` 回到 Java，随后 dispatcher 才能：

```text
save guest context
issue exact HandoffYield
suspend old admission
admit FIFO head
```

### 4.9 Immutable CommandInvocationContext

```java
public final class CommandInvocationContext {
    private final int command;
    private final String origin;
    private final String detail;
    private final String contextKey;
    private final Map<String, String> projectedProperties;
}
```

构造后不允许修改：

```java
this.projectedProperties = Collections.unmodifiableMap(
        new LinkedHashMap<>(projectedProperties));
```

context 的可见性由 admission 控制，而不是由 caller 写入时间控制：

```java
public CommandInvocationContext getAdmittedCommandContext() {
    CommandInvocationRecord invocation = admittedInvocation;

return invocation != null
            && invocation.getState() == State.ADMITTED
            ? invocation.getContext()
            : null;
}
```

因此：

```text
B 已创建，但 A 仍 ADMITTED  -> runtime reader 仍读 A
A SUSPENDED                 -> runtime reader 回到 legacy fallback
B ADMITTED                  -> runtime reader 读 B
B TERMINAL                  -> B context 撤销
A 显式恢复                  -> runtime reader 再读 A
```

### 4.10 Legacy System property 只作为投影适配器

现有项目可能已经有大量 `System.getProperty()` reader，无法一次性全部改造。可以使用一个严格的 projection adapter：

```java
public synchronized void activate(
        CommandInvocationContext context) {

if (activeContext != null) {
        throw new IllegalStateException(
                "command context already active");
    }

Map<String, String> previous = new LinkedHashMap<>();

for (Map.Entry<String, String> entry
            : context.getProjectedProperties().entrySet()) {

previous.put(entry.getKey(),
                System.getProperty(entry.getKey()));

setOrClear(entry.getKey(), entry.getValue());
    }

previousValues = previous;
    activeContext = context;
}
```

撤销时精确恢复之前的“存在状态和值”：

```java
public synchronized void deactivate(
        CommandInvocationContext context) {

if (activeContext != context) {
        throw new IllegalStateException(
                "command context is not active");
    }

for (Map.Entry<String, String> entry
            : previousValues.entrySet()) {
        setOrClear(entry.getKey(), entry.getValue());
    }

previousValues = Collections.emptyMap();
    activeContext = null;
}
```

它不是新的全局状态源，而是 legacy reader 的迁移桥。长期目标仍然是让行为代码通过 admitted context reader 取值。

### 4.11 Context 不进入 JNI ABI

context 是 Java-side ownership token，不应该塞进 guest `Object... args`，否则会改变 native ABI。

调用链采用 overload 显式传递：

```java
public JniInvocationOutcome<?> callStaticJniMethodObjectOutcome(
        CommandInvocationContext context,
        Emulator<?> emulator,
        String method,
        long timeout,
        TimeUnit unit,
        Object... args) {

CommandInvocationOutcome outcome = callJniMethodOutcome(
            emulator,
            vm,
            this,
            context,
            method,
            timeout,
            unit,
            args);

return resolveInvocationOutcome(outcome);
}
```

底层仍按原 JNI positional ABI 编组：

```text
x0 = JNIEnv
x1 = jclass / jobject
x2... = 原有 native arguments
```

`CommandInvocationContext` 只附着到 scheduled mailbox record，不进入 guest 寄存器。

### 4.12 Exact CommandInvocationOutcome

```java
public final class CommandInvocationOutcome {
    private final Number value;
    private final CommandResult result;
    private final int command;
    private final long generation;
    private final CommandInvocationReferenceScope referenceScope;
}
```

构造器必须拒绝任何拼接结果：

```java
public CommandInvocationOutcome(
        CommandInvocationRecord invocation,
        CommandResult result) {

if (invocation == null
            || result == null
            || invocation.getTerminalResult() != result
            || !result.isCommandTerminal()
            || !result.isForInvocation(
                    invocation.getCommand(),
                    invocation.getGeneration(),
                    invocation.getSubmitterThread().getId())) {

throw new IllegalArgumentException(
                "result does not belong to command invocation");
    }

this.value = result.getValue();
    this.result = result;
    this.command = invocation.getCommand();
    this.generation = invocation.getGeneration();
    this.referenceScope = invocation.getReferenceScope();
}
```

这里使用对象 identity：

```java
invocation.getTerminalResult() == result
```

即使另一个结果拥有完全相同的 command、generation 和 submitter，只要它不是 record 实际保存的 terminal，也不能冒充本次 outcome。

### 4.13 Terminal 完成只写入一次

```java
synchronized boolean complete(CommandResult result) {
    if (!result.isCommandTerminal()) {
        return false;
    }

if (terminalResult == null) {
        terminalResult = result;
        state = State.TERMINAL;
    }

return true;
}
```

dispatcher 完成 record 时统一补 ownership：

```java
result = result.withCommandOwnership(
        record.getCommand(),
        record.getGeneration(),
        record.getSubmitterThread().getId(),
        record.getSubmitterThread().getName());

record.complete(result);
```

后续重复 terminal producer 只能得到已有 terminal，不得覆盖：

```java
if (record.getTerminalResult() != null) {
    return record.getTerminalResult();
}
```

这关闭了 watchdog TIMEOUT、natural completion 和 fault retirement 之间的双发布竞争。

### 4.14 Invocation-scoped JNI local references

先定义一个与具体 VM 解耦的生命周期接口：

```java
public interface CommandInvocationReferenceScope {
    void bindToCarrier();
    void markCarrierRetired();
    void acknowledgeOutcome();
    void discardUnbound();
    boolean isClosed();
}
```

Android DVM 提供具体实现：

```java
final class InvocationLocalReferenceScope
        implements CommandInvocationReferenceScope {

private final BaseVM vm;
    private final Map<Integer, ObjRef> references =
            new HashMap<>();

private boolean bound;
    private boolean carrierRetired;
    private boolean outcomeAcknowledged;
    private boolean closed;
}
```

tracked JNI 参数不再进入 VM-wide map：

```java
private static void addPreparedLocalObject(
        VM vm,
        CommandInvocationReferenceScope scope,
        DvmObject<?> object) {

if (scope == null) {
        vm.addLocalObject(object);       // legacy 顺序路径
        return;
    }

((BaseVM) vm).addInvocationLocalObject(scope, object);
}
```

guest JNI 运行时也根据当前 running carrier 找到 scope：

```java
private InvocationLocalReferenceScope
currentInvocationReferenceScope() {

CommandInvocationReferenceScope scope =
            dispatcher.getRunningCommandInvocationReferenceScope();

return scope instanceof InvocationLocalReferenceScope
            ? (InvocationLocalReferenceScope) scope
            : null;
}
```

因此 `addLocalObject()` 和 `getObject()` 自动路由：

```java
public int addLocalObject(DvmObject<?> object) {
    InvocationLocalReferenceScope scope =
            currentInvocationReferenceScope();

if (scope != null) {
        return scope.addLocalObject(object);
    }

return addObject(object, false, false);
}
```

### 4.15 Reference scope 的双闩锁释放

真正释放必须同时满足：

```text
carrierRetired == true
outcomeAcknowledged == true
```

```java
private void releaseWhenReady(
        boolean retired,
        boolean acknowledged,
        boolean unbound) {

Map<Integer, ObjRef> released;

synchronized (this) {
        if (closed) {
            return;
        }

carrierRetired |= retired;
        outcomeAcknowledged |= acknowledged;

if (unbound && bound) {
            return;
        }

if (!unbound
                && (!carrierRetired || !outcomeAcknowledged)) {
            return;
        }

closed = true;
        released = new HashMap<>(references);
        references.clear();
    }

vm.deleteInvocationLocalRefs(released);
}
```

为什么两个条件缺一不可？

- 只有 `carrierRetired`：Java 还没通过 native handle 解析返回对象；
- 只有 `outcomeAcknowledged`：carrier 可能因 TIMEOUT 返回给 caller，但 guest 仍未真正退役；
- 两者都满足：guest 不再使用参数，caller 也已经解析结果，可以安全执行 `onDeleteRef()`。

### 4.16 DVM outcome 先解析对象，再 acknowledge

```java
CommandInvocationReferenceScope scope = null;

try {
    CommandInvocationOutcome outcome = callJniMethodOutcome(...);
    scope = outcome.getReferenceScope();

Number handle = outcome.getValue();

DvmObject<?> value = handle == null
            ? null
            : vm.getInvocationObject(scope, handle.intValue());

return new JniInvocationOutcome<>(value, outcome);
} finally {
    if (scope != null) {
        scope.acknowledgeOutcome();
    }
}
```

这与旧的 `finally { vm.deleteLocalRefs(); }` 有本质区别：旧代码清空整个 VM 的 local refs，新代码只确认本 invocation 的 outcome 已解析；实际释放仍等待 carrier retirement。

### 4.17 Tracked RuntimeException 发布 exact FAULT

在 emulator 的 RuntimeException 处理路径中，先判断当前 running task 是否拥有 tracked invocation：

```java
catch (RuntimeException e) {
    if (dispatcher.publishCommandInvocationFault(e)) {
        set(EMU_REASON_KEY, Reason.FAULT);
        set(EMU_FAULT_KEY, e);
        return null;
    }

return legacyHandleException(e);
}
```

dispatcher 将 fault 绑定到 carrier：

```java
public boolean publishCommandInvocationFault(
        RuntimeException fault) {

Task task = currentRunningTask();

synchronized (this) {
        if (task == null || recordsByCarrier.get(task) == null) {
            return false;
        }
    }

pendingFaults.put(task,
            CommandResult.fault("tracked backend fault", fault));
    return true;
}
```

原 submitter 后续只消费自己 record 的 pending fault：

```java
CommandResult fault =
        consumePendingFaultForInvocation(invocation);

if (fault != null) {
    return retireFaultedCarrierAndComplete(invocation, fault);
}
```

Legacy runtime exception 仍走旧兼容路径，避免一次重构破坏所有历史调用。

### 4.18 显式 Route，禁止通过运行状态猜路径

是否进入 tracked mailbox 应由 call site 明确声明，而不是根据“dispatcher 当前是否活跃”猜测：

```java
public enum CommandInvocationRoute {
    LEGACY_DIRECT,
    TRACKED_ASYNC_MAIN_MAILBOX,
    TRACKED_ASYNC_WORKER_MAILBOX
}
```

```java
switch (route) {
    case LEGACY_DIRECT:
        return invokeLegacyCommand(...);

case TRACKED_ASYNC_MAIN_MAILBOX:
        return invokeTrackedCommand(
                context,
                CommandCarrierPolicy.SCHEDULED_MAIN,
                ...);

case TRACKED_ASYNC_WORKER_MAILBOX:
        return invokeTrackedCommand(
                context,
                CommandCarrierPolicy.SCHEDULED_WORKER,
                ...);
}
```

显式 route 有三个好处：

1. initial/direct 调用不会因为 backend 恰好活跃而误入 mailbox；
2. worker carrier policy 不需要从 origin、线程名或环境变量推断；
3. code review 能直接看到哪些调用被允许参与 tracked overlap。

### 4.19 持久异步 worker：每条 command 独立 record

真实程序经常使用 persistent single-thread executor：

```java
final class NativeEventWorker implements AutoCloseable {
    private final ExecutorService worker =
            Executors.newSingleThreadExecutor();

private final CommandExecutor commandExecutor;
}
```

一个 job 可以包含多条命令：

```java
private void execute(EventJob job) {
    for (EventCommand command : job.getCommands()) {
        CommandResult result = commandExecutor.execute(command);

if (!isExactCompletedTerminal(command, result)) {
            fail(job, command, result);
            return;
        }
    }
}
```

注意：persistent worker identity 不等于 persistent backend admission。

正确模型是：

```text
同一个 Java worker
  command #1 -> generation N   -> terminal N
  command #2 -> generation N+1 -> terminal N+1
  command #3 -> generation N+2 -> terminal N+2
```

每条 native command 都创建独立 record，worker FIFO 只保证业务提交顺序。不能把整个 job 合并成一个大 record 或长时间独占 backend，否则会抹掉主分支与 worker 分支之间真实存在的 safe-point overlap。

### 4.20 Durable terminal ledger

调度架构正确之后，还需要保证运行结果可评价。JUnit PASS 只代表测试方法结束，不代表 native transaction 完整。

一个简单可靠的账本使用 UTF-8 JSONL：

```java
final class TransactionTerminalLedger
        implements AutoCloseable {

private final ExecutorService writer =
            Executors.newSingleThreadExecutor();

private final AtomicReference<IOException> writerFailure =
            new AtomicReference<>();

private long nextSequence;
}
```

创建文件时使用 `CREATE_NEW`，防止覆盖旧运行：

```java
Files.newBufferedWriter(
        file,
        StandardCharsets.UTF_8,
        StandardOpenOption.CREATE_NEW,
        StandardOpenOption.WRITE);
```

每条事件通过单 writer 顺序写入并立即 flush：

```java
public void writeLine(String line) throws IOException {
    writer.write(line);
    writer.newLine();
    writer.flush();
}
```

典型事件包括：

```text
RUN_START
COMMAND_TERMINAL
TRANSACTION_TERMINAL
RUN_END
```

完整性判定只看最后一条：

```java
static boolean isCaptureComplete(Path file)
        throws IOException {

List<String> lines = Files.readAllLines(
            file, StandardCharsets.UTF_8);

return !lines.isEmpty()
            && lines.get(lines.size() - 1)
                    .contains("\"event\":\"RUN_END\"");
}
```

如果 writer 失败，`finish()` 或 `close()` 必须向测试抛出 IOException，不能出现“控制台日志看起来正常，但权威账本没有落盘”的假成功。

---

## 五、完整运行链：一辆车让路，另一辆车通过，再恢复原车

代码结构只有在完整时序中才能看清。下面用 A、B 两次调用说明最终模型。

![图片描述](upload/attach/202607/1072248_DMAUVCGKNGXSVWM.webp)

这张时序图刻意把 `emu_stop()` 和 `natural return` 画成两种不同事件：前者只负责把 owner 拉回 safe point，后者才有资格形成 `COMPLETED`。

### 5.1 A 首先取得 admission

```text
A caller 创建 immutable context
A createBound invocation
A request handoff
backend 当前空闲
A 成为 FIFO head
A -> ADMITTED
A context projection activate
A carrier 取得 backend capability
A guest 开始执行
```

此时：

```text
admittedInvocation = A
backendOwner = A.submitter
runtimeContext = A.context
A.state = ADMITTED
```

### 5.2 B 在另一个宿主线程提交

```text
B caller 创建自己的 context
B 原子 create-and-bind
B 加入 handoff FIFO
```

B 仍然只是 `BOUND`：

```text
B.state = BOUND
runtimeContext 仍然是 A
```

这是 admitted-only 语义最重要的时刻。B 的 Java caller 已经存在，但 guest 仍在执行 A，所以任何 runtime reader 都必须继续看到 A。

### 5.3 B 请求 backend stop

B 是 FIFO head，并发现 backend owner 属于已 admitted 的 A，于是调用：

```java
backend.emu_stop();
```

这不是终态，只是让 A 的 active `emu_start()` 回到 Java。

### 5.4 A 在 safe point 暂停

dispatcher 获得当前 owner-session generation 和 safe-point sequence：

```text
save A PC/SP/register context
create exact HandoffYield for B
deactivate A context
A ADMITTED -> SUSPENDED
admittedInvocation = null
```

A 的 carrier 没有 destroy，reference scope 也没有释放。A 只是暂时离开桥面。

### 5.5 B admitted 并自然返回

```text
B 成为 FIFO head
B BOUND -> ADMITTED
activate B context
B carrier acquire backend capability
B guest 执行
B natural return
B record stores exact COMPLETED terminal
deactivate B context
B carrier retired
B caller receives CommandInvocationOutcome
B caller resolves DVM return handle
B outcome acknowledged
B reference scope closes
```

B 的 terminal 必须带有：

```text
B.command
B.generation
B.submitterThreadId
```

任何全局 last result 都不能替代它。

### 5.6 A 只能由原 submitter 显式恢复

A 不会被 dispatcher 自动塞回 FIFO。原 submitter 再次请求 admission：

```text
A SUSPENDED -> handoff request
A becomes FIFO head
A -> ADMITTED
activate A context
restore A PC/SP/registers
A guest 从原 safe point 后继续
```

最终形成可验证序列：

```text
guest runtime context: A -> B -> A
backend owner:          A -> B -> A
terminal ownership:    B terminal only belongs to B
saved CPU context:     A resumes from exact saved point
```

### 5.7 为什么不能把整个异步 job 当成一辆超长卡车

假设一个 persistent worker 需要提交六条 native command，同时主分支可能在中间提交一条 command。

错误模型：

```text
worker 获得一次 admission
连续执行六条 command
完成后才释放 backend
```

这会抹掉真实 overlap，使主分支无法在 worker command 之间取得执行机会。

正确模型：

```text
persistent Java worker identity
  -> command 1 独立 invocation
  -> command 2 独立 invocation
  -> main command 可在 safe point 插入
  -> command 3 独立 invocation
  -> ...
```

Java executor FIFO 与 backend handoff FIFO 是两个正交层：

- executor FIFO 保证事件内部顺序；
- handoff FIFO 保证并发 caller 申请 backend 的顺序；
- 每条 command 都拥有独立 generation 和 terminal；
- 任一 command 失败后，executor 停止后续 job，但不会把失败伪装成完成。

---

## 六、验证、迁移策略与能力边界

架构重构最危险的地方，是 synthetic 测试通过后立刻宣称复杂业务已经修好。正确做法是分层验证，每层只证明自己的合同。

### 6.1 第一层：纯状态机测试

应覆盖：

- reservation 只能由 original submitter bind 或 cancel；
- context command 与 carrier command 不一致时拒绝；
- 两个并发 caller 原子 create-and-bind，不暴露 unbound reservation；
- 三个 submitter 按真实请求顺序进入 FIFO；
- 非 FIFO head 不得 admitted；
- stale owner-session token 不得 suspend 当前 invocation；
- stale safe-point sequence 不得 suspend；
- suspended invocation 不会自动恢复；
- same command、different generation 不串槽；
- foreign terminal 不得构造 outcome。

### 6.2 第二层：真实 Unicorn backend handoff

使用最小 AArch64 guest 程序验证：

```text
A 进入循环并保持可观测寄存器
B 从另一个 Java 线程提交
B 请求 emu_stop
A emu_start 返回
A 保存上下文并 SUSPENDED
B 写入标志并 RET
B 获得 exact terminal
A 原 submitter显式恢复
A 从原 PC/SP/X0 继续并 RET
```

必须断言：

- cross-thread `emu_stop()` 使 active emulation 返回；
- A 的 PC/SP/关键寄存器恢复一致；
- B 执行期间 A 不继续运行；
- B terminal 不污染 A；
- runtime context 现场观察为 A→B→A；
- SUSPENDED A 不被普通 picker 选中。

### 6.3 第三层：DVM/JNI outcome 测试

应覆盖：

- context 不进入 JNI argument ABI；
- exact DVM API 能返回 value + owned terminal；
- 注入同 command、错误 generation 的 global terminal，不影响本次 outcome；
- `Object[]` 参数在另一个 invocation 完成后仍可读取；
- reference scope 只有双条件满足才释放；
- fake handle 或 JNI RuntimeException 形成 exact FAULT，而不是 COMPLETED `-1`。

### 6.4 第四层：Persistent worker FIFO

应覆盖：

- 同一 Java worker 执行多条命令；
- 每条命令拥有不同 generation；
- worker command 全部使用 worker carrier policy；
- main command 能在 worker 序列中通过真实 safe point handoff；
- main suspend 期间保持现场；
- worker job 不持有一个跨命令的大 admission；
- TIMEOUT、FAULT、CANCELLED 立即停止当前与排队 job。

### 6.5 第五层：持久终态证据

一次长运行只有满足以下条件才可评价：

```text
文件成功 CREATE_NEW
RUN_START 已写入
每条 command terminal 带 exact ownership
transaction terminal 已写入
最后一条为 RUN_END
writer failure 能让测试失败
```

如果 stdout 被截断，而 JSONL 没有 `RUN_END`，结论只能是：

```text
CAPTURE_INCOMPLETE
```

不能用 JUnit PASS 或日志前半段推断业务成功、失败或架构充分性。

### 6.6 从旧代码迁移时不要一次性删除 legacy 路径

推荐迁移顺序：

1. 保留第一版 timeslice、futex 和 Task 调度；
2. 增加 Invocation record，但仅用于新 tracked route；
3. 将 exact outcome API 接入 synthetic caller；
4. 迁移真正影响运行行为的 context reader；
5. 纯 observation reader 暂时保留 legacy fallback；
6. 明确哪些 caller 使用 direct route，哪些使用 tracked mailbox；
7. 为每个异步 branch 做完整 route closure，禁止只迁移其中一条命令；
8. tracked 路径稳定后，再缩减全局 last-result 和 active fields；
9. 最后才清理 legacy 单槽、旧 ENV 和历史日志分支。

不建议全仓机械替换 `activeCommand`。某些读取只是日志标签，某些读取会改变 JNI 返回形状，两者的迁移风险完全不同。

### 6.7 第一版、第二版与最终版对比

| 维度 | 第一版时间片 | 第二版命令服务 | 最终 Invocation Runtime |
|---|---|---|---|
| 核心目标 | 让 Task 轮流运行 | 避免多人同时驾驶 backend | 让重叠调用拥有精确生命周期 |
| 调度单位 | Task | Task + command | Task + Invocation |
| backend 停止 | timeslice / futex | stop + owner handoff | exact safe-point yield |
| backend 权限 | 调度循环隐式拥有 | owner thread | OwnerSession + logical admission |
| 调用身份 | command 或 active field | command + 若干 generation 槽 | carrier + command + generation + submitter |
| 请求顺序 | Task round-robin | 全局 handoff 状态 | Invocation FIFO |
| 运行上下文 | 全局 active fields | global/ThreadLocal 混合 | immutable admitted-only context |
| 返回结果 | Number/null | value + global result heuristic | record-owned exact outcome |
| 异常 | 可能兼容为 -1 | pending global fault | invocation-owned FAULT |
| JNI local ref | VM-wide map | VM-wide map | invocation scope |
| scope 释放 | JNI finally 全清 | carrier/task 清理 | carrier retired AND outcome acknowledged |
| timeout | 总 wall time | watchdog + 多个全局槽 | exact terminal，operation cancellation 分离 |
| 可评价证据 | stdout | stdout + JUnit | durable terminal ledger |

### 6.8 这次重构解决了什么

它解决的是 unidbg 单 backend 多线程模拟的通用基础设施问题：

- backend 可以在不同宿主 submitter 之间安全交接；
- 调用可以在真实 safe point 暂停和恢复；
- 同 command 多 generation 不再覆盖；
- caller context 不会在未 admitted 时污染当前 guest；
- value 与 terminal 不再通过全局槽拼接；
- 暂停调用的 JNI handles 不会被其他调用清除；
- RuntimeException 不再被伪装成成功数值；
- 长运行具有明确的完整性判据。

### 6.9 它没有承诺什么

这套架构没有承诺：

- 自动还原所有目标程序的业务状态；
- synthetic handoff 通过就意味着复杂业务输出正确；
- 单 backend 能获得真机级别的真正并行；
- 任意 timeout 都可以通过延长时间解决；
- 所有 legacy caller 都应该改成 tracked mailbox；
- 一个 persistent worker 应该长期独占 backend；
- 可以用 timeout、null 或 `EMU_STOP` 冒充自然完成。

多线程基础设施正确，只说明“车辆、桥权、货单和回执没有串错”。车辆为什么没有装上某批货物，仍然可能是更上层的业务状态问题。

---

## 七、把工程记忆写进仓库：Agent可继承的协作闭环

我个人是从 AI 时代才开始接触逆向的，分享一点自己的实践心得,并且本文也在ai的帮助下撰写。

如果只把 AI 当成即时问答工具，协作很容易陷入循环。第一轮花很长时间解释背景，第二轮因为上下文增长开始遗忘旧约束，第三轮又提出已经验证失败的方案，几轮之后，历史假设可能被误写成当前事实。代码确实改了不少，但没有人能准确回答每一次修改究竟证明了什么。这并不完全是模型是否会写代码的问题，更关键的是工程有没有建立可继承的记忆系统。聊天记录适合讨论，却不适合作为唯一事实源；它会被截断和压缩，重要信息也会散落在不同轮次中。真正可持续的做法，是把协作所需的状态、证据、禁区和结论写进仓库，让任何一轮新的分析都从同一个基线出发。

因此，我们没有维护一篇包揽所有内容的“万能说明书”，而是让不同文档承担不同职责。 `AGENTS.md` 保存协作规则，说明进入任务前要读什么、哪些文件能够修改、哪些操作需要额外授权，以及实验产物应放在哪里。它更像施工现场的安全规范，解决的是“应该怎样工作”，而不是“今天具体做到了哪里”。

`progress.md` 是按时间增长的工程账本。一次实验修改了什么、没有修改什么，观察到了哪些原始现象，结论能够覆盖到哪一层，下一步停在哪里，都应当在这里留下记录。它保存的不是一份经过修饰的成功故事，而是完整的决策轨迹。后来的协作者不必依靠一句“这里以前试过”，而是可以查到当时试了什么、控制条件是否成立，以及为什么那个结果不能继续外推。

`experiment_outcomes_and_pivots.md` 专门保存负向知识。一般的开发记录喜欢写“最后怎样成功”，却很少认真记录“哪些路为什么不通”。在复杂重构中，失败实验并不是垃圾，它会缩小候选空间。提高优先级、延长 timeout、强制 wake、扩大全局锁或者增加兼容 fallback，这些都是面对并发异常时很容易再次想到的方案。如果历史已经证明它们只能改变表象，转向账本就应明确写出原假设、反证和新的方向。这样，新一轮 AI 在读取状态后，需要提出能够区分新解释的验证，而不是把旧补丁换一个参数再做一遍。

`CURRENT_STATE.md` 承担的角色更接近总工程师确认后的最新图纸。时间线账本可以不断追加观察，但稳定状态不应随着每次未经复核的实验来回摆动。把“实验记录”和“当前可信结论”分开，是为了防止一条单样本结果立刻改写整个架构叙事。它也明确提醒 AI：发现新的可能性并不等于已经获得修改全局结论的权力。

随着进展账本越来越长，仅靠读取文件末尾也会逐渐丢失阶段脉络，截至今天，我项目的 `progress.md` 已经30多万行，如果想让一个从来没接触过项目的ai进站了解项目去读这个文件，显然并不可能，所以我们又用 `summarization/07` 这类按月份和日期组织的文档保存阶段检查点。它们的核心不是压缩当天日志，而是建立一种可继承的推理架构——每篇文献都遵循一套稳定的结构契约：

- 承接链：开篇声明承接哪一篇、覆盖 `progress.md` 的哪一行区间，让每一轮分析都能精确回到上一轮的停点，而不是从头猜上下文；
- 概览锚点：当日覆盖的实验阶段列表、核心认知转折、以及一句话收口，相当于状态寄存器的快照；
- 主线演进（而非流水账）：按认知转折分组叙述，区分"发现了什么"和"它改变了什么假设"，避免日记体式的平铺；
- 正向实验：每个 P 编号段记录原假设、修改范围、观察结果和收窄结论，形成可逐层追溯的因果链；
- 等价禁区：每篇日终都会显式列出当日新增和强化的"已证伪/禁止回退方向"。这不是附注，而是架构的关键组成部分——没有它，负向知识就会在下一轮被遗忘，曾经失败过的方案会再次被提出。把这个列表和实验记录一起持久化，是防止路线循环的唯一机制；
- 多层根因：根因不是一句笼统的结论，而是按层次拆解——对照层、当前修复状况层、仍暴露的窄层、以及长期线。每一层独立演进，不因下层修复而自动闭合上层；
- 显式前沿与下一步：每篇结束前写明"当前最窄根因"和排序后的下一步方向，让下一篇可以从精确的前沿而非全局重启；
- 一句话收口：强制性的单句压缩，确保即使只读第一页也能恢复整篇的核心判断。

这些文档组成了一套分层的工程记忆。规则文档负责限制行为，当前状态负责提供稳定基线，进展账本负责保存时间线，转向账本负责阻止路线循环，阶段摘要负责跨越上下文边界，对外文章则负责把内部经验脱敏后重新组织为可传播的方法。它们并不是重复记录同一件事，而是在不同粒度上回答不同问题。新一轮协作也不需要把整个仓库和全部历史一次性塞给 AI，只要从稳定状态、近期进展和相关阶段摘要恢复现场，再根据当前问题有方向地读取源码即可。

有了这套记忆系统，每次开始工作都可以执行同一个“进站”过程。先读取最新状态和历史转向，再对照禁止清单，随后确认本轮问题位于因果链的哪一层，明确允许修改的文件和能够接受的证据，最后才开始分析或实现。完成后，代码通过测试只是第一层检查，还要确认测试究竟证明了什么、哪些结论仍未覆盖，并在明确停点结束。这样做可以抑制一种很常见的冲动：看到某处出现差异，就自动向上游追踪；看到一个 timeout，就马上延长等待；看到一个全局字段，就顺手做全仓替换。每一步都必须先回答，它修复或验证的是因果链中的哪一层。

---
## 结语

第一版原生时间片方案解决了 unidbg 多线程模拟最基础的问题：没有稳定 safe point，就谈不上可控调度。它让主任务和 worker 不再完全依赖偶然 syscall 才能轮转，是从补丁式 drain 走向调度基础设施的关键一步。

第二版命令服务进一步意识到 backend 不能被多个宿主线程同时驾驶，也开始区分 timeout、fault、handoff 和 completion。但只要调用身份仍散落在全局 result、command 单槽、active fields 和日志字符串中，重叠调用就没有严格的隔离边界。

最终重构真正改变的是系统的主语：过去所有逻辑都在问“下一个 Task 跑谁”，现在系统还会问“正在运行的是哪一次 Invocation，它为什么有资格进入 backend，它暂停时应保存什么，它的结果和 JNI 引用最终交给谁”。

红绿灯只能让车轮流过桥。要让一座单车道桥长期、安全地承载复杂交通，还需要通行证、流水号、排队规则、货单隔离、交接凭证和不可抵赖的出桥记录。

对于 unidbg 的单后端多线程模拟来说，真正困难的从来不是“多跑几个 worker”，而是让每一次暂停、恢复、返回、超时和失败，都精确地属于正确的那次调用。

而对于长期的人机协作来说，真正困难的也不是让 AI 多生成几段代码，而是让每一次观察、假设、修改、验证和转向，都精确地写入正确的工程记忆，并能被下一轮工作完整继承。

以上是我个人在 unidbg 调度模型上的一点粗浅思考，受限于水平和经验，难免有疏漏或偏颇之处，欢迎读者批评指正。

*本文仅讨论 unidbg 开源框架自身调度模型的通用架构设计。文中所有命令编号、回调与返回值均为抽象占位符，不对应任何特定程序、接口或业务数据。本文不提供、不指引、不协助绕过任何具体安全防护措施。*

回复或点赞可查看完整内容

传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！！

最后于 2026-8-17 10:56 被mxystery编辑，原因：

#源码框架 #逆向分析 #工具脚本

最新回复 (24)
mb_cfjwplfo 雪币： 319 能力值： ( LV1，RANK：0 ) 在线值：发帖 6 回帖 95 粉丝 20 关注私信	mb_cfjwplfo 2 楼还没碰到过多线程的so，有没有案例 2026-7-14 20:02 0
mxystery 雪币： 2468 活跃值： (1058) 能力值： ( LV6，RANK：90 ) 在线值：发帖 6 回帖 5 粉丝 16 关注私信	mxystery 2 3 楼 mb_cfjwplfo 还没碰到过多线程的so，有没有案例大厂的一些安全sdk 2026-7-14 20:23 0
mb_ldbucrik 雪币： 6 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 707 粉丝 7 关注私信	mb_ldbucrik 4 楼想大佬学习 2026-7-14 20:41 0
wx_插曲雪币： 411 活跃值： (986) 能力值： ( LV2，RANK：10 ) 在线值：发帖 2 回帖 323 粉丝 24 关注私信	wx_插曲 5 楼 66 2026-7-15 12:46 0
九黎雪币： 51 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 93 粉丝 0 关注私信	九黎 6 楼 tql 2026-7-15 17:37 0
拍拖雪币： 2790 活跃值： (7141) 能力值： ( LV6，RANK：90 ) 在线值：发帖 22 回帖 436 粉丝 15 关注私信	拍拖 2 7 楼感谢分享！ 2026-7-16 14:40 0
YANG、雪币： 22 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 37 粉丝 0 关注私信	YANG、 8 楼感谢分享！ 2026-7-16 18:06 0
mb_ddpergdx 雪币： 200 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 7 粉丝 0 关注私信	mb_ddpergdx 9 楼 2026-7-16 18:51 0
amwpecel 雪币： 17 活跃值： (1761) 能力值： ( LV2，RANK：10 ) 在线值：发帖 1 回帖 118 粉丝 1 关注私信	amwpecel 10 楼 666 2026-7-17 08:12 0
dob_C 雪币： 131 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 86 粉丝 0 关注私信	dob_C 11 楼感谢分享 2026-7-17 16:12 0
FMNS 雪币： 9 活跃值： (2021) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 122 粉丝 1 关注私信	FMNS 12 楼 666 2026-7-17 16:51 0
wx_Huber Barrientos 雪币： 0 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 216 粉丝 1 关注私信	wx_Huber Barrientos 13 楼 666 2026-7-18 03:17 0
uni7corn 雪币： 0 活跃值： (2485) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 182 粉丝 0 关注私信	uni7corn 14 楼感谢分享 2026-7-20 15:56 0
iBa0 雪币： 1901 活跃值： (5923) 能力值： ( LV4，RANK：40 ) 在线值：发帖 6 回帖 490 粉丝 37 关注私信	iBa0 15 楼 123 2026-7-22 10:52 0
wx_Dispa1r 雪币： 1963 活跃值： (4327) 能力值： ( LV4，RANK：55 ) 在线值：发帖 5 回帖 138 粉丝 4 关注私信	wx_Dispa1r 16 楼 1 2026-7-23 19:51 0
mb_ebihoycp 雪币：能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 16 粉丝 0 关注私信	mb_ebihoycp 17 楼 666 2026-7-23 20:18 0
mb_cbgtaveo 雪币： 292 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 259 粉丝 0 关注私信	mb_cbgtaveo 18 楼 666666 2026-7-23 21:42 0
MaYil 雪币： 9440 活跃值： (8067) 能力值： ( LV2，RANK：10 ) 在线值：发帖 1 回帖 484 粉丝 2 关注私信	MaYil 19 楼感谢分享 2026-7-23 21:57 0
mb_uvyukvot 雪币： 209 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 144 粉丝 1 关注私信	mb_uvyukvot 20 楼 666 2026-7-27 17:48 0
简单的简单雪币： 10936 活跃值： (9283) 能力值： ( LV8，RANK：130 ) 在线值：发帖 18 回帖 210 粉丝 190 关注私信	简单的简单 1 21 楼 666 2026-7-27 19:43 0
三明治拉拉雪币： 20 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 9 粉丝 0 关注私信	三明治拉拉 22 楼 666 2026-8-11 19:35 0
puppet_w 雪币： 1247 活跃值： (958) 能力值： ( LV2，RANK：10 ) 在线值：发帖 1 回帖 68 粉丝 10 关注私信	puppet_w 23 楼 6666 2026-8-24 15:46 0
mb_elqvlqkf 雪币：能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 4 粉丝 0 关注私信	mb_elqvlqkf 24 楼大佬666 2026-9-24 02:56 0
mb_lfwgtxdb 雪币： 8 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 68 粉丝 0 关注私信	mb_lfwgtxdb 25 楼感谢分享 2026-9-24 09:11 0
	游客登录 \| 注册方可回帖回帖表情雪币赚取及消费高级回复