文件描述符跨 Java、JNI 和多个 SO 时由谁关闭

fd 数值不是资源身份，关闭后可能被复用

文件描述符是当前进程描述符表的索引。代码看到整数相同，只能说明某个时刻使用了同一槽位，不能证明它仍对应原文件、socket、管道或设备。原 owner 关闭后，系统可能把相同数值分配给新资源；迟到线程若继续使用旧整数，就会操作完全无关的对象。

跨 JNI 传递时应创建逻辑 resourceId，并在每次拥有关系变化时推进 generation。事件记录 resourceId、generation、fdSnapshot、owner、action 和 terminal。fdSnapshot 只用于调试，状态机按 resourceId 与 generation 判定。这样即使整数复用，旧 generation 的迟到 close 也会被门禁拒绝。

Java 对象引用同样不等于 Native 所有权。包装对象可能被关闭、复制或被另一个组件接管，Native 侧只保存整数会失去生命周期信息。桥接接口要把 ownershipMode 和 generation 作为显式参数或由受控句柄表维护，不从对象是否非空推断资源仍有效。

borrow、duplicate 和 transfer 必须三选一

borrow 表示调用期间临时使用，所有权仍属于调用方。借用方不得关闭、缓存到调用结束之后或交给异步任务，除非合同另行延长借用期。JNI 方法返回前，借用令牌失效；Java 侧可以在确认无未完成借用后关闭。异常返回不会把 borrow 自动升级为 transfer。

duplicate 表示通过明确复制操作获得新 fd，接收方负责关闭自己的副本。复制失败时所有权不变；成功后两个 owner 各有唯一 close 责任。副本可能共享底层打开文件描述及偏移等状态，具体语义按所用 API 核对，因此并发读写仍需业务协调，不能因为整数不同就假设完全隔离。

transfer 表示接收方在成功点接管原 fd，发送方立即把本地状态改为 moved 并清除可调用入口。成功点必须唯一且可记录，通常是接收方确认登记资源之后。若传递中途失败，契约说明所有权回滚给发送方还是由接收方清理，不能让双方都认为对方负责。

接口要让所有权从类型和名称上可见

JNI 方法若只接收 jint fd，调用点无法看出它会借用还是接管。更清楚的设计是拆成 nativeReadBorrowed、nativeDuplicateForWorker 和 nativeTakeOwnership，或者传递带 ownershipMode、resourceId 和 generation 的不可变请求对象。返回值包含 acceptedGeneration 与 terminal，调用方据此更新状态。

多个 SO 之间的 C 接口也要维持同一语义。函数名、头文件、版本和返回状态明确 transfer 成功点，结构体不放语言运行库所有权对象。若库内部再把资源交给另一个模块，生成新的 owner event；外部调用方不需要知道内部 fd 数值，但要能看到自己的 ownership 已经结束。

日志字符串不能充当协议。诸如“fd accepted”或“already closed”容易随语言与实现变化，也不能驱动 Java 状态。公开结果使用有限枚举 accepted、rejected、moved、closed 和 invalid_generation；诊断文本仅供人工分析，不触发再次 close 或重试。

异常、取消与 pending exception 必须走同一清理状态机

Native 操作可能在登记前、登记后、实际 I/O、回调或清理阶段失败。每个阶段都要说明当前 owner。异常路径不能跳过状态迁移，也不能在 catch 中无条件 close 原始整数。统一出口根据 state 决定：owned 才允许关闭，borrowed 只结束借用，moved 不做 close，closed 仅记录重复请求。

协程或任务取消不是资源关闭的同义词。取消方先标记任务终态并阻止新 I/O，再由当前 owner 执行 close；异步工作线程结束后返回 close receipt。若 Java 页面销毁但 Native 工作仍按合同执行，页面不能直接关闭 borrowed fd，需通过 owner 的取消接口协调。

JNI pending exception 存在时，Native 仍要完成允许的最小资源状态更新，但不要继续复杂 JNI 调用。close 失败保存为 secondary error，不能覆盖原 pending exception。返回 Java 后，上层根据单一公开终态处理，不同时从返回值、异常和日志猜测资源是否已经关闭。

跨线程时先停止新使用，再由 owner 关闭

一个线程关闭 fd 时，另一个线程可能正在使用相同整数。系统调用终态与平台行为要按具体 API 核对，应用层不能依赖“close 会自动安全唤醒所有等待者”。资源对象需要 acceptingOperations 标志、活动操作计数和 owner generation。关闭流程先拒绝新操作，再等待或取消已登记操作，最后由 owner 执行一次 close。

线程回调携带 resourceId 与 generation，完成时再次核对。旧 generation 的结果不得写入新资源，即便 fdSnapshot 碰巧相同。若工作池需要长期持有，应使用 duplicate 或 transfer，不让短期 borrow 越过方法返回。引用计数只管理逻辑借用，不取代底层唯一 owner 的 close 责任。

SO 卸载尝试也是生命周期事件。若库中仍有 owner、活动操作或关闭回调，卸载会让函数指针和清理代码失效。移动 App 通常让核心 Native 库随进程常驻更容易证明；需要动态模块时，先完成 drain、验证 close receipts，再允许卸载，未完成资源阻止切换。

测试要覆盖整数复用、失败交接和进程终态

普通成功用例只能证明一条路径。回归矩阵还要覆盖 borrow 方误关、duplicate 失败、transfer 登记前失败、transfer 成功后旧 owner 使用、取消与 close 竞态、close 失败、JNI pending exception、线程池迟到回调和模拟整数复用。每个用例断言状态机终态，而不是只检查没有崩溃。

instrumented test 可以从 Android 应用上下文创建受控资源、触发 JNI、重建页面和取消任务。测试使用临时公开安全数据，不碰真实用户文件。每份回执绑定 App、SO、ABI、设备、resourceId 事件摘要和候选哈希；单一设备通过不代表全部系统与厂商。

进程退出时，操作系统会回收进程资源，但这不能证明应用生命周期正确。退出前泄漏会造成长期运行资源耗尽，也可能掩盖未完成写入。ApplicationExitInfo 用于把异常退出与候选和时间窗关联；正常测试仍要在进程存活时验证所有 owned 资源都有唯一 close receipt。

用生命周期事件门禁发现重复关闭和退出泄漏

事件文件可以使用抽象 resourceId、generation、actor、action 和 mode，不记录真实路径或用户内容。检查器为每个资源维护 owner、状态和最后代际，按顺序处理 create、borrow、borrow_end、duplicate、transfer、use、close 和 process_end。任何借用方关闭、moved 后使用、重复 close 或退出仍有 owner 都拒绝。

下面的 Python 代码从命令行读取事件。输入缺失时直接非零退出；它要求 sequence 严格递增、create 唯一、actor 与 owner 匹配，并在 process_end 检查所有资源已关闭或明确 transferred_external。示例不执行真实 I/O，不提供内网或攻击步骤，只验证资源账本。

真实项目要扩展 duplicate 新 resourceId、transfer 回滚、并发操作计数和 close failure，但不能放松单一 owner 原则。门禁通过只证明事件自洽，采集点是否覆盖所有 JNI 与 SO 入口仍需代码审查和设备回执确认。

import json
import sys
from pathlib import Path

def stop(message):
    print(f"fd lifecycle rejected: {message}", file=sys.stderr)
    raise SystemExit(2)

def load_events(path_text):
    path = Path(path_text)
    if not path.is_file():
        print("fd lifecycle rejected: event file is missing", file=sys.stderr)
        raise SystemExit(2)
    try:
        return json.loads(path.read_text(encoding="utf-8"))
    except (OSError, json.JSONDecodeError) as exc:
        stop(f"cannot parse events: {exc}")

def validate(data):
    events = data.get("events")
    if not isinstance(events, list) or not events:
        stop("events must be a non-empty list")
    resources = {}
    previous_sequence = -1
    for event in events:
        sequence = event.get("sequence")
        if type(sequence) is not int or sequence <= previous_sequence:
            stop("event sequence is not strictly increasing")
        previous_sequence = sequence
        resource = event.get("resourceId")
        action = event.get("action")
        actor = event.get("actor")
        if action == "create":
            if not resource or resource in resources or not actor:
                stop("create has an invalid resource or owner")
            resources[resource] = {"owner": actor, "state": "owned", "borrower": None}
            continue
        if action == "process_end":
            leaked = [key for key, value in resources.items() if value["state"] == "owned"]
            if leaked:
                stop(f"process ended with owned resources: {sorted(leaked)}")
            continue
        state = resources.get(resource)
        if state is None:
            stop("event references an unknown resource")
        if action == "borrow":
            if state["state"] != "owned" or actor == state["owner"]:
                stop("borrow has an invalid owner or borrower")
            state["borrower"] = actor
        elif action == "borrow_end":
            if actor != state["borrower"]:
                stop("borrow_end comes from the wrong actor")
            state["borrower"] = None
        elif action == "transfer":
            if actor != state["owner"] or not event.get("newOwner"):
                stop("transfer comes from the wrong owner")
            state["owner"] = event["newOwner"]
        elif action == "use":
            if actor not in {state["owner"], state["borrower"]} or state["state"] != "owned":
                stop("use comes from an actor without ownership")
        elif action == "close":
            if actor != state["owner"] or state["state"] != "owned":
                stop("close is duplicated or comes from a non-owner")
            state["state"] = "closed"
        else:
            stop(f"unknown action: {action}")
    print(f"fd lifecycle accepted: {len(events)} events")

if __name__ == "__main__":
    if len(sys.argv) != 2:
        stop("usage: check_fd_events.py events.json")
    validate(load_events(sys.argv[1]))

发布门禁绑定候选、契约和唯一 close 回执

发布前列出所有跨 Java、JNI 和 SO 的 fd 入口，为每个入口指定 ownershipMode、成功点、失败回滚、取消策略和 close owner。静态接口审查后运行事件矩阵，门禁确认每个 create 最终只有一个 close，borrow 方从不 close，transfer 后旧 owner 的任何事件都被拒绝。

加固、JNI 签名、异常翻译、线程模型、动态库边界或 API level 变化后，重新生成候选哈希并重跑关键矩阵。旧事件可以帮助比较，不能替新候选签字。若描述符泄漏只在长时间运行出现，增加受控循环与资源计数，但不虚构泄漏已消失。

站内的 JNI 错误转换文章可继续检查 close 失败和 pending exception 的公开终态；准备评估商业 App 的 SO 加固与跨层资源契约时，可通过页面行动按钮进入御盾中央平台提交候选包和 fd 接口清单。提交只启动评估，关闭责任结论仍以同一候选回执为准。

• 所有 fd 入口显式选择 borrow、duplicate 或 transfer。
• resourceId 与 generation 取代整数作为长期身份。
• 异常、取消和 pending exception 进入同一资源状态机。
• 借用方从不关闭，转移后原 owner 立即失效。
• 正常与失败路径都产生唯一 close receipt。
• 候选变化后重跑复用、竞态、卸载与退出矩阵。