Shared Memory Transport

1.1 操作系统层面的共享内存#

共享内存是 POSIX IPC（进程间通信）中效率最高的方式——多个进程直接映射同一块物理内存到自己的虚拟地址空间，无需任何内核数据搬运：

核心机制：

与 UDP 传输的本质区别：UDP 必须经过 用户态 → 内核态 → 网络 → 内核态 → 用户态 的完整路径；SHM 直接在用户态完成，不经过内核协议栈。

1.2 Fast DDS SHM 传输架构#

Fast DDS 的 SHM 传输基于 Boost.Interprocess 库实现，核心组件如下：

关键组件说明（参考官方文档 Definition of Concepts）：

关键理解：SHM Transport 在传输层用共享内存替代了网络，但数据仍然需要从应用拷贝到 DataWriter history（含序列化），再从 DataReader history 拷贝到应用（含反序列化）。SHM Transport 消除的是传输层的拷贝（即 UDP 中 sendto/recvfrom 的内核态拷贝），而非应用层与 DDS 中间件之间的拷贝。

1.3 数据流对比：SHM vs UDP#

将 SHM 的数据流与 UDP 对比，可以直观看出为什么 SHM 性能远超 UDP：

UDP 传输路径（4~6 次拷贝）：

SHM Transport 传输路径（2~3 次拷贝）：

1.4 SHM Transport / Data-sharing / Zero-Copy 三者关系#

Fast DDS 中有三个不同层次的”共享内存”机制，它们不是同一个东西：

三者是递进关系：

面试高频点：很多人说”SHM Transport = 零拷贝”，这是不准确的。SHM Transport 只是消除了传输层的内核态拷贝，应用与 DataWriter/DataReader history 之间仍有拷贝。真正的端到端零拷贝需要 Data-sharing delivery + loan API 的配合。详见 Zero-Copy communication。

1.5 发现机制：SHM 与 UDP 的关系#

SHM 只能用于同一台机器上的进程间通信，无法替代 UDP 的组播发现功能。Fast DDS 的典型做法是 SHM + UDP 同时注册：

Fast DDS 在发现阶段通过 UDP 组播交换 Locator 信息。当发现对方也在同一台机器上时，会自动切换到 SHM 传输数据，无需用户干预。

2.1 默认行为#

Fast DDS 默认启用 SHM 传输。如果你没有做任何自定义配置，Fast DDS 会自动注册 SHM + UDP 两种传输：

• 本地通信 → 自动走 SHM
• 远程通信 → 自动走 UDP

大多数情况下，你不需要额外配置 SHM。只有当你需要调优 SHM 参数或禁用 SHM 时，才需要显式配置。

2.2 XML 配置#

1
<!-- 示例 1：仅使用 SHM 传输（禁用 UDP，仅限本地通信） -->
2
<profiles>
3
    <participant profile_name="shm_only" is_default_profile="true">
4
        <rtps>
5
            <userTransports>
6
                <transport_id>shm_transport</transport_id>
7
            </userTransports>
8
            <useBuiltinTransports>false</useBuiltinTransports>
9
        </rtps>
10
    </participant>
11
</profiles>
12

13
<library_settings>
14
    <intraprocess_delivery>FULL</intraprocess_delivery>
15
</library_settings>
16

17
<!-- SHM 传输描述符 -->
18
<transport_descriptors>
19
    <transport_descriptor>
20
        <transport_id>shm_transport</transport_id>
21
        <type>SHM</type>
22
        <segment_size>104857600</segment_size>          <!-- 100 MB 共享内存段 -->
23
        <port_queue_capacity>1024</port_queue_capacity>  <!-- 端口队列深度 -->
24
        <healthy_check_timeout_ms>1000</healthy_check_timeout_ms>
25
        <rtps_dump_file>shm_dump.log</rtps_dump_file>    <!-- 调试用，生产环境关闭 -->
26
    </transport_descriptor>
27
</transport_descriptors>

1
<!-- 示例 2：SHM + UDP 混合模式（推荐，本地走 SHM，远程走 UDP） -->
2
<transport_descriptors>
3
    <!-- SHM 传输 -->
4
    <transport_descriptor>
5
        <transport_id>shm_transport</transport_id>
6
        <type>SHM</type>
7
        <segment_size>104857600</segment_size>
8
    </transport_descriptor>
9

10
    <!-- UDP 传输（用于发现和远程通信） -->
11
    <transport_descriptor>
12
        <transport_id>udp_transport</transport_id>
13
        <type>UDPv4</type>
14
        <sendBufferSize>4194304</sendBufferSize>
15
        <receiveBufferSize>4194304</receiveBufferSize>
16
    </transport_descriptor>
17
</transport_descriptors>
18

19
<profiles>
20
    <participant profile_name="shm_udp_hybrid" is_default_profile="true">
21
        <rtps>
22
            <userTransports>
23
                <transport_id>shm_transport</transport_id>
24
                <transport_id>udp_transport</transport_id>
25
            </userTransports>
26
            <useBuiltinTransports>false</useBuiltinTransports>
27
        </rtps>
28
    </participant>
29
</profiles>

2.3 C++ API 配置#

1
#include <fastdds/rtps/transport/shared_memory/SharedMemTransportDescriptor.h>
2
#include <fastdds/rtps/transport/UDPv4TransportDescriptor.h>
3

4
using namespace eprosima::fastdds::rtps;
5

6
// 1. 配置 SHM 传输
7
auto shm_transport = std::make_shared<SharedMemTransportDescriptor>();
8
shm_transport->segment_size = 100 * 1024 * 1024;       // 100 MB 共享内存段
9
shm_transport->port_queue_capacity = 1024;              // 端口队列深度
10
shm_transport->healthy_check_timeout_ms = 1000;         // 健康检查超时
11

12
// 2. 配置 UDP 传输（用于发现和远程通信）
13
auto udp_transport = std::make_shared<UDPv4TransportDescriptor>();
14
udp_transport->sendBufferSize = 4 * 1024 * 1024;
15
udp_transport->receiveBufferSize = 4 * 1024 * 1024;
16

17
// 3. 注册传输
18
DomainParticipantQos pqos;
19
pqos.transport().use_builtin_transports = false;        // 禁用默认传输
20

21
TransportDescriptorList transports;
22
transports.push_back(shm_transport);                    // SHM 优先
23
transports.push_back(udp_transport);                    // UDP 兜底
24
pqos.transport().user_transports = transports;
25

26
// 4. 创建 Participant
27
DomainParticipant* participant =
28
    DomainParticipantFactory::get_instance()->create_participant(0, pqos);

2.4 关键参数说明#

segment_size 的选择原则：segment_size 必须大于同一时刻驻留在共享内存中的所有消息的总大小。以 2 MB 点云、10 Hz 为例，如果接收端能在 100ms 内处理完一帧，则共享段中最多同时存在 12 帧，segment_size 至少需要 48 MB。建议留 24 倍余量，设为 3264 MB。

3.1 核心指标对比#

注意：上表是仅使用 SHM Transport（未开启 Data-sharing / Zero-Copy）的数据。如果进一步开启 Data-sharing + loan API（即 Zero-Copy 模式），拷贝次数可降至 0 次，序列化也可跳过，CPU 占用可降至 5% 以下。详见 Zero-Copy communication。

3.2 实测数据参考#

以 128 线激光雷达点云（2 MB/帧，10 Hz）为例：

结论：对于本地大数据传输，SHM Transport 已经能显著提升性能（消除内核态拷贝和系统调用）。如果进一步开启 Zero-Copy（Data-sharing + loan API），可以将 CPU 占用降至最低。UDP 即使经过充分调优，在 2 MB 级别消息场景下也很难达到满帧率。

4.1 优点#

4.2 缺点#

4.3 适用场景#

Q1：共享内存为什么快？#

答：SHM Transport 快在两个层面：

1. 消除内核态拷贝：UDP 必须经过 sendto()（用户态→内核态）和 recvfrom()（内核态→用户态），SHM 全程在用户态完成，无上下文切换开销。
2. 无协议开销：不需要 UDP/IP/以太网头部封装（约 98 字节），不需要分片/重组，不需要校验和计算。

但 SHM Transport 仍有 2~3 次拷贝（应用↔DataWriter/DataReader history 的序列化/反序列化拷贝）。如果要进一步消除这些拷贝，需要开启 Data-sharing + loan API（即 Zero-Copy 模式）。

Q2：SHM Transport 和 Zero-Copy 是什么关系？#

答：它们不是同一个东西，是递进关系：

• SHM Transport：传输层机制，用共享内存替代网络传输，消除内核态拷贝。但应用↔DataWriter/DataReader history 之间仍有 2~3 次拷贝。
• Data-sharing delivery：QoS 层机制，直接共享 DataWriter 的 history 给 DataReader，消除 history ↔ 传输层的拷贝。
• Zero-Copy：应用层机制，结合 Data-sharing + loan_sample() / return_loan() API，应用直接写/读共享内存，实现端到端 0 次拷贝。

三者关系：UDP → SHM Transport（消除内核态拷贝）→ Zero-Copy（消除所有拷贝）。

Q3：SHM 能完全替代 UDP 吗？#

答：不能。原因：

1. SHM 仅限同一台物理机上的进程间通信，无法跨网络。
2. SHM 不支持组播，而 Fast DDS 的参与者发现（SPDP）依赖 UDP 组播。
3. 实际项目中通常 SHM + UDP 混合使用：发现走 UDP 组播，本地数据走 SHM，远程数据走 UDP。

Q4：共享内存的 segment_size 怎么设置？#

答：segment_size 必须大于同一时刻驻留在共享内存中的所有消息的总大小。计算方法：

1
最小 segment_size = 单条消息最大大小 × 同时驻留的消息数 × 安全余量

以 2 MB 点云、10 Hz 为例：如果接收端能在 100ms 内处理完一帧，同时驻留 12 帧，最小需要 4 MB。建议留 24 倍余量，设为 32~64 MB。

设置过小会导致消息发送失败（共享段满），设置过大浪费物理内存。

Q5：共享内存的同步机制是怎样的？#

答：Fast DDS SHM 使用以下同步机制：

• 互斥锁（mutex）：保护共享内存池的分配/回收操作，防止多进程同时操作导致数据竞争。
• 条件变量（condition variable）：发送端写入数据后通知接收端，接收端不需要轮询等待，避免 CPU 空转。
• 引用计数：接收端持有数据引用时，该缓冲区不会被回收，保证数据完整性。

Q6：SHM 传输需要序列化吗？#

答：需要。SHM Transport 默认仍然会进行 CDR 序列化，因为 DDS 的数据类型是跨语言、跨平台的，序列化保证了数据的一致性。

如果要跳过序列化，需要开启 Data-sharing delivery + loan API（即 Zero-Copy 模式）：

• 配置 DataSharingQosPolicy 为 AUTO 或 ON
• 使用 loan_sample() 直接借用 DDS 中间件的共享内存缓冲区写入数据
• 接收端使用 return_loan() 归还缓冲区

这样应用直接写共享内存，接收端直接读同一块内存，全程无序列化。详见 Zero-Copy communication。

Q7：SHM 传输的异常退出怎么处理？#

答：进程异常退出（如 crash、kill -9）时，共享内存段不会被自动释放，可能导致：

• 共享段残留，占用物理内存
• 锁未释放，导致其他进程死锁

Fast DDS 的处理方式：

• healthy_check_timeout_ms 参数：定期检查共享段的健康状态，超时后触发恢复。
• remove_on_destroy 参数：设为 true 时，正常退出会清理共享段（但异常退出无法触发）。
• 生产建议：在启动脚本中加入共享内存清理逻辑（如 rm /dev/shm/fastdds*）。

Q8：如何判断当前走的是 SHM 还是 UDP？#

答：三种方法：

1. 开启 Fast DDS 日志：设置日志级别为 Info，启动时会打印使用的传输类型。
2. 查看 Locator：通过 DataReader 的 matched_publisher_data() 查看对方的 Locator _kind，LOCATOR_KIND_SHM (16) 表示 SHM，LOCATOR_KIND_UDPv4 (1) 表示 UDP。
3. 操作系统工具：Linux 下用 ls /dev/shm/ 查看是否有 Fast DDS 的共享内存段；用 ipcs -m 查看共享内存使用情况。

Q9：SHM 和进程内传输（Intraprocess）有什么区别？#

答：

如果所有 DataWriter 和 DataReader 都在同一个进程内，优先使用 Intraprocess；如果是不同进程，使用 SHM。两者可以同时启用。

Q10：SHM 传输有哪些局限性？#

答：

1. 跨机器不可用：SHM 仅限同一物理机，无法替代网络传输。
2. 内存占用：共享段占用物理内存，segment_size 过大可能影响系统其他进程。
3. 调试困难：不像网络包可以抓包分析，SHM 的数据传递需要用专门的工具或日志。
4. 异常恢复：进程异常退出可能导致共享段残留或锁死，需要额外的清理机制。
5. 安全隔离：共享内存对同一台机器上的所有进程可见（除非设置权限），不适合传输敏感数据。