您问了一些问题，但我将重点关注典型 shared_ptr 实现使用的排序约束，因为我认为这涵盖了您问题的关键部分。
原子操作对于它所应用的变量（或 POD）而言是始终原子的；对单个变量的修改将以一致的顺序对所有线程可见。
您的问题中描述了轻松的原子操作的工作方式：
std::memory_order_relaxed 对于同一个变量仍然是原子的，但不提供关于其他数据的加载和存储的任何其他约束
以下是 2 个典型场景，其中可以省略原子操作的排序约束（即通过使用 std::memory_order_relaxed）：
-
内存排序不是必需的，因为它不依赖于其他操作，或者正如评论者所说，(..) 不是涉及其他内存位置的不变量的一部分。
一个常见的例子是原子计数器，它由多个线程递增以跟踪特定事件发生的次数。
如果计数器表示的值不依赖于其他操作，则可以放宽递增操作 (fetch_add)。
我发现 cppreference 给出的例子不是很有说服力，因为 shared_ptr 引用计数 does 有依赖关系；即一旦它的值变为零，内存就会被删除。
一个更好的例子是 Web 服务器跟踪传入请求的数量，仅用于报告目的。
-
内存排序是必要的，但没有需要使用排序约束，因为所需的同步已经通过
（IMO 这更好地解释了为什么 shared_ptr 的引用计数增量可以放宽，请参见下面的示例）。
shared_ptr 复制/移动构造函数只能在它具有（引用）复制/移动实例的同步视图时调用（否则它将是未定义的行为）
因此，无需额外订购。
以下示例说明了shared_ptr 实现通常如何使用内存排序来修改其引用计数。假设所有线程并行运行
之后 sp_main 已被释放（shared_ptr 引用计数为 10）。
int main()
{
std::vector<std::thread> v;
auto sp_main = std::make_shared<int>(0);
for (int i = 1; i <= 10; ++i)
{
// sp_main is passed by value
v.push_back(thread{thread_func, sp_main, i});
}
sp_main.reset();
for (auto &t : v) t.join();
}
void thread_func(std::shared_ptr<int> sp, int n)
{
// 10 threads are created
if (n == 7)
{
// Only thread #7 modifies the integer
*sp = 42;
}
// The only thead with a synchronized view of the managed integer is #7
// All other threads cannot read/write access the integer without causing a race
// 'sp' going out of scope -> destructor called
}
线程创建保证make_shared（在main）和sp的复制/移动构造函数（在每个线程内）之间的（线程间）发生前关系。
因此，shared_ptr 的构造函数具有内存的同步视图，并且可以安全地递增 ref_count 而无需额外排序：
ctrlblk->ref_count.fetch_add(1, std::memory_order_relaxed);
对于销毁部分，由于只有线程#7写入共享整数，所以其他9个线程不允许访问相同的内存位置而不会引起竞争。
这会产生一个问题，因为所有线程几乎在同一时间被破坏（假设main 中的reset 之前已被调用）
并且只有一个线程会删除共享整数（将 ref_count 从 1 递减到 0）。
最后一个线程在删除整数之前必须有一个同步的内存视图，但由于 10 个线程中有 9 个没有同步视图，因此需要额外的排序。
析构函数可能包含如下内容：
if (ctrlblk->ref_count.fetch_sub(1, std::memory_order_acq_rel) == 1)
{
// delete managed memory
}
原子ref_count 有一个单一的修改顺序，因此所有原子修改都以某种顺序发生。
假设在 ref_count 上执行最后 3 次递减的线程（在此示例中）是线程 #7 (3 → 2)、#5 (2 → 1) 和 #3 (1 → 0)。
线程#7 和#5 执行的两个递减在修改顺序中都比#3 执行的递减更早。
发布顺序变为：
#7（商店发布）→#5（读取-修改-写入，无需订购）→#3（加载获取）
最终结果是线程#7执行的释放操作已经与#3执行的获取操作同步，并且整数修改（#7）保证有
发生在整数销毁之前（#3）。
从技术上讲，只有访问托管内存位置的线程必须执行释放操作，但由于库实现者不知道线程操作，
所有线程在销毁时执行释放操作。
对于共享内存的最终销毁，技术上只有最后一个线程需要执行获取操作，因此shared_ptr 库实现者可以通过设置独立围栏进行优化
仅由最后一个线程调用。
if (ctrlblk->ref_count.fetch_sub(1, std::memory_order_release) == 1)
{
std::atomic_thread_fence(std::memory_order_acquire);
// delete managed memory
}