过度使用智能指针（尤其是shared_ptr）是否会增加系统内核调用？

我正在优化并简化一个QNX实时代码库，核心优化方向包括内存/实时效率，以及减少系统内核调用。之前了解到过度以传值方式使用std::shared_ptr会带来运行时性能损耗，现在想确认这种实现是否也会触发额外的内核调用。

需要注意的是，processSend是一个**周期性调用（间隔数毫秒）**的函数，它还会以同样的传值方式调用Default等其他函数，代码示例如下：

// getting called in every cycle (some milliseconds)
void signal::processSend(
    std::shared_ptr<const structA> readPtrA,
    std::shared_ptr<const structB> readPtrB,
    std::shared_ptr<const structC> readPtrC) {
        last_send_data = this->Default(readPtrA, readPtrB, readPtrC);
}

void signal::Default(
    std::shared_ptr<const structA> readPtrA,
    std::shared_ptr<const structB> readPtrB,
    std::shared_ptr<const structC> readPtrC) {
              // some value readings
}

解答 #

默认实现的std::shared_ptr传值操作本身不会直接触发内核调用，因为它的引用计数增减是用户态的原子操作（依赖CPU指令级的原子加减，比如fetch_add），不需要陷入内核。

但在QNX实时系统环境下，需要留意几个可能间接引发内核调用的场景：

• 当shared_ptr的引用计数归零触发对象析构时，如果析构函数中包含内核操作（比如释放共享内存、关闭文件句柄等），此时才会产生内核调用，但这属于业务逻辑的副作用，并非shared_ptr传值本身导致。
• 若使用了自定义的shared_ptr删除器（deleter），且该删除器涉及内核操作，也可能在引用计数归零后触发内核调用，但同样不属于传值操作的直接结果。

针对你这种毫秒级周期的高频调用场景，传值shared_ptr的主要性能损耗来自用户态的原子操作开销：每次传值都会执行一次原子的引用计数加1，函数返回时再执行原子减1。虽然不是内核调用，但高频场景下多次原子操作的累积延迟会影响实时性，这也是需要重点优化的点。

优化建议

• 将函数参数改为const std::shared_ptr<const structA>&（const引用），避免每次调用都触发引用计数的原子增减，彻底消除这部分开销。
• 如果能确保指针在函数调用期间不会被销毁，甚至可以直接传递原始指针const structA*，进一步简化调用，但必须严格保证指针的生命周期安全。

内容的提问来源于stack exchange，提问作者Khashayar