嘿，针对你的问题，咱们拆解来看：

首先得搞清楚：delete本身并不会直接插入锁逻辑，但它依赖的底层内存回收机制（比如标准库的free）往往会加锁——这和new的情况是对称的，毕竟默认情况下new/delete共享同一套内存分配器。

C++98中的表现 #

C98标准并没有强制要求内存分配器的线程安全性，但在实际的主流编译器实现（比如GCC、MSVC）里，默认的free（也就是delete最终调用的底层函数）都会带上锁。毕竟C98时代多线程程序已经很常见，编译器厂商会主动做这个兼容，所以默认delete基本都会有锁操作，没法直接用于无锁场景。

C++11的变化 #

C++11把标准库内存分配器的线程安全性纳入了标准要求——也就是说，多线程同时调用默认的new/delete时，不会出现数据竞争。这就意味着默认delete的底层实现必须有同步机制（比如锁）来保证内存池的安全。

不过这里有个灵活点：如果你自定义了无锁的内存分配器，并且重载了operator delete来使用这个分配器，那delete就不会产生锁。标准只约束默认实现，不限制用户自定义的分配器行为。

总结一下 #

• 不管是C98还是C11，默认的delete实现几乎都会因为底层内存回收的需求加锁：C98是厂商实现的惯例，C11是标准强制要求。
• 要在无锁软件里用delete，必须自己实现无锁内存分配器，并重载operator delete来替代默认的带锁版本。

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