ROS2 零拷贝通信：loaned messages 与线程安全

ROS2 默认的消息传输路径中，数据从发布者到订阅者至少经历一次完整拷贝，对图像、点云这类大消息，拷贝开销显著。本文介绍 rclcpp 零拷贝（loaned message）API 的语义与边界，分析它与 Executor 线程模型的冲突，并给出订阅端回调的实践约束。适合已熟悉 ROS2 通信机制、需要为大数据量场景评估零拷贝方案的读者。

零拷贝 API 的语义

发布侧：借出、写入、归还

Publisher::borrow_loaned_message() 向中间件借一块内存，写入数据后通过 publish(std::move(...)) 归还并转移所有权：

cpp

// 1. 向中间件借一块内存（而非自己分配）
auto loaned_msg = pub->borrow_loaned_message();

// 2. 直接往这块内存里写数据
loaned_msg.get().data = 42.0;

// 3. 发布——所有权转移给中间件，loaned_msg 此后不可再访问
pub->publish(std::move(loaned_msg));

publish(std::move(...)) 之后 loaned_msg 失效，再访问它是未定义行为。

内存的分配与回收权始终在中间件手里，这正是零拷贝的前提。如果中间件不支持 loan（例如 rmw_cyclonedds），borrow_loaned_message() 会自动回退到本地分配器：API 不变，只是不再零拷贝；Publisher::can_loan_messages() 可以提前查询中间件是否支持。另外，loaned message 设计上只支持定长（POD）消息类型，含变长字段的 msg 无法走这条路径。

订阅侧：默认拿到拷贝

即使中间件支持 loan，订阅端默认也会先拷贝一份再传给回调：

cpp

void callback(const Msg::UniquePtr msg) {
    // 默认情况下，msg 指向本地拷贝而非共享内存
}

ROS_DISABLE_LOANED_MESSAGES 环境变量是全局禁用开关：设为 1 强制回退普通发布/订阅路径，默认未设置（等价于不禁用）。

数据流

线程模型对比

标准模式（非零拷贝）

DDS 收数据线程 --> 拷贝到 ROS 消息 --> Executor 调度 --> 用户回调

中间件线程拷贝一份完整的 ROS 消息
Executor 在 ROS 侧线程中调用回调
回调操作的是私有拷贝，天然线程安全

零拷贝模式

共享内存段 --> 引用计数 +1 --> Executor 调度 --> 用户回调 --> 引用计数 -1
     ^                                              |
     +---------- 引用计数归零时回收内存 ---------------+

关键区别：回调操作的是共享内存中的同一份数据，不是私有拷贝。

三个核心问题

发布者会覆盖订阅者正在读的数据吗？

不会。iceoryx / Fast DDS 的共享内存使用引用计数机制：发布者写新数据时，如果旧 chunk 还有订阅者在读，中间件会分配一个新 chunk 给发布者；旧 chunk 在引用计数归零后才回收。

时间线：
Publisher:  写 chunk_A -------- 写 chunk_B -------- 写 chunk_C
Subscriber:    +-- 读 chunk_A --+                     (A 引用计数 > 0，不回收)
                                             chunk_A 引用计数=0，可回收

发布者会因订阅者太慢而阻塞吗？

不会。零拷贝模式下发布者不等待订阅者。订阅者消费太慢时，根据 QoS History 策略，旧 chunk 被安全溢出，订阅者丢失旧数据、拿到最新数据。这与 socket 通信的背压机制不同——过载时的表现是丢数据，而不是发送端减速。

订阅端 loaned message 为什么不安全？

问题出在 rclcpp 的 Executor 模型与共享内存生命周期的冲突：

SingleThreadedExecutor——回调串行执行。但回调里如果做了异步操作（如把 UniquePtr 传给另一个线程），共享内存可能在另一个线程访问时已被回收。
MultiThreadedExecutor——多个回调并行执行。如果两个回调引用了同一个共享内存 chunk（History depth > 1 时可能发生），且一个回调修改了数据，就会产生数据竞争；C++ 类型系统并不阻止这种修改。
根本矛盾——rclcpp 的 UniquePtr 语义假设消息是独占所有的，但共享内存 chunk 的生命周期由中间件管理。Executor 释放 UniquePtr 时，中间件可能还没准备好回收；反过来，中间件已回收但 rclcpp 还持有引用。

这是 rmw_fastrtps#614 中讨论的核心问题，写作时仍未完全解决。

两种模式对比

特性	标准模式	零拷贝模式
数据所有权	订阅者拥有私有拷贝	中间件拥有，订阅者只有引用
发布者阻塞	可能（网络背压）	不会（新分配 chunk）
回调线程安全	天然安全（私有数据）	需要额外保证
内存回收	离开作用域即回收	引用计数归零后回收
内存耗尽风险	无（堆分配）	有（`RETCODE_OUT_OF_RESOURCES`）
适合场景	通用	大数据 + 单线程/可控的回调

实践建议

cpp

// 正确：回调中尽快处理完，不传出引用
void callback(const Msg::UniquePtr msg) {
    process(msg->data);  // 就地处理
    // 离开作用域，引用计数 -1
}

// 危险：把共享内存指针传给其他线程
void callback(const Msg::UniquePtr msg) {
    std::thread([msg]() {  // msg 的共享内存可能已被回收
        process(msg->data);
    }).detach();
}

// 危险：回调中长时间持有
void callback(const Msg::UniquePtr msg) {
    std::this_thread::sleep_for(100ms);  // 占用共享内存 chunk 100ms
    // 发布者高频发送时，共享内存池会耗尽
}

订阅端回调必须就地处理数据：不传出引用、不做异步操作、不长时间持有。否则要么触发 use-after-free，要么耗尽共享内存池。

小结

发布侧 loaned message 是低风险的优化：API 形态不变，中间件不支持时自动回退本地分配，语义上只有「publish 之后不可再访问」这一条新约束。
零拷贝的正确性压力集中在订阅端：回调拿到的是共享内存数据时，必须就地处理，不传出引用、不异步、不长期持有。
消息类型须为定长 POD；变长字段的消息无法走零拷贝路径。
过载行为与 socket 背压相反：不阻塞发送端，而是按 QoS History 丢弃旧数据；持续持有 chunk 则可能耗尽共享内存池。

ROS2 零拷贝通信：loaned messages 与线程安全 ​

零拷贝 API 的语义 ​

发布侧：借出、写入、归还 ​

订阅侧：默认拿到拷贝 ​

数据流 ​

线程模型对比 ​

标准模式（非零拷贝） ​

零拷贝模式 ​

三个核心问题 ​

发布者会覆盖订阅者正在读的数据吗？ ​

发布者会因订阅者太慢而阻塞吗？ ​

订阅端 loaned message 为什么不安全？ ​

两种模式对比 ​

实践建议 ​

小结 ​