Unreal 智能指针原理分析

TSharedPtr，有两个成员，占用 16 个字节，分别是对象指针和引用控制器。控制器内有两个计数器 Shared 和 Weak。

• ObjectType* Object
• FSharedReferencer< Mode > SharedReferenceCount
  • TReferenceControllerWithDeleter* SharedReferenceCount（引用控制器+对象销毁器）
    • std::conditional_t<Mode == ESPMode::ThreadSafe, std::atomic<int32>, int32> SharedReferenceCount、WeakReferenceCount（Shared、Weak 计数，用两个计数器的作用之后会提到）
    • ObjectType* Object（保存要销毁的对象）

TWeakPtr 内的是 FWeakReferencer，其内部也是 TReferenceControllerWithDeleter，之所以有区分，可以看下 ConditionallyAddSharedReference 小节
TSharedRef 内部和 TSharedPtr 基本一致，没有提供空构造函数，而且在赋值和构造函数内，都会用 check 保证指针非空。
SharedFromThis 是在类内存了个 WeakPtr，以便原始指针生成智能指针。
TUniquePtr 内部只有一个对象指针。

计数管理

在 ReleaseSharedReference 后判断没有 SharedReferenceCount 后，会调用 DestroyObject 和 ReleaseWeakReference。而 ReleaseWeakReference 后判断没有 WeakReferenceCount 后，则是销毁引用计数器（TReferenceControllerBase）。

在新建 TReferenceControllerBase 的时候，SharedReferenceCount 和 WeakReferenceCount 都是 1。不管外面创建多少个 SharedPtr 和 WeakPtr，都至少是 1。只有当最后一个 SharedPtr 销毁的时候，ReleaseSharedReference 才会让 SharedReferenceCount 变成 0，销毁对象；然后自动调用 ReleaseWeakReference，销毁引用控制器。

所以 WeakReferenceCount 的作用其实是在 SharePtr 都没了的情况下，保留住引用控制器，告诉所有的 WeakPtr 你们已经 isn’t valid 了。

销毁对象使用的函数是 DestroyObject：this->InvokeDeleter(Object)，调用 Invoke 触发传入的自定义 Delete 函数。若是没有传入 delete，那么创建的 TReferenceControllerWithDeleter 使用的 DeleterType 就是 struct DefaultDeleter，其销毁函数实现就是直接 delete 了：void operator()(Type* Object) const { delete Object; }

使用方面

因为一个对象的所有智能指针都是通过引用控制器管理的，所以拿智能指针的原始指针再创建一个智能指针是一定会出问题的，因为这个过程创建了一个新的引用控制器。

// Non-copyable
TReferenceControllerBase(const TReferenceControllerBase&) = delete;
TReferenceControllerBase& operator=(const TReferenceControllerBase&) = delete;

所以传递的情况下，如果其它地方也需要强引用住对象，还是传递智能指针吧。
不过 SharedFromThis 也是解决这种问题的一种方式。

SharedFromThis

在创建 TSharedPtr 的时候，会调用 SharedPointerInternals::EnableSharedFromThis，如果对象是 TSharedFromThis 类型，就会特化带有内容的 EnableSharedFromThis 函数模板，调用 TSharedFromThis::UpdateWeakReferenceInternal，其作用是在 TSharedFromThis 类内部，让一个 TWeakPtr 保存住引用控制器信息，这样其它地方就可以通过原始指针，生成智能指针了。
这个 TWeakPtr 在 SharedPtr 都销毁的时候调用的析构函数内会被销毁，所以析构流程是没什么问题的。

ConditionallyAddSharedReference

用一个 WeakPtr 创建 SharedPtr，有一种情况是：

• 虽然 ReferenceController 还在但是对象已经销毁了，这种情况是只剩下一些 WeakPtr 了，这些 WeakPtr 的 IsValid 也会返回 false。
  这种情况，SharedPtr 在创建的时候，FSharedReferencer 的构建函数内调用 ReferenceController->ConditionallyAddSharedReference，在 SharedReferenceCount 为 0 的情况下，会直接返回 false，然后 FSharedReferencer 将 ReferenceController 置空。然后因此 TSharedPtr 内的 Object 也就还是 nullptr 了。

FORCEINLINE explicit TSharedPtr( TWeakPtr< OtherType, Mode > const& InWeakPtr )
	: Object( nullptr )
	, SharedReferenceCount( InWeakPtr.WeakReferenceCount )
{
	if( SharedReferenceCount.IsValid() )
	{
		Object = InWeakPtr.Object;
	}
}

FSharedReferencer( FWeakReferencer< Mode > const& InWeakReference )
	: ReferenceController( InWeakReference.ReferenceController )
{
	if( ReferenceController != nullptr )
	{
		if( !ReferenceController->ConditionallyAddSharedReference() )
		{
			ReferenceController = nullptr;
		}
	}
}

MakeShareable、MakeShared

MakeShareable，接收一个对象指针，创建一个结构体 TRawPtrProxy，将传入的对象指针，复制到内部的对象指针上。当然，还有一个带有 Deleter 的版本，结构体为 TRawPtrProxyWithDeleter，这里就不细讲了。
然后 TSharedPtr 有以 TRawPtrProxy 为参数的构造、赋值函数，将该结构体内的对象指针设到 TSharedPtr 内部的对象指针上。
所以整个过程创建了一个临时的结构体对象，两次指针赋值操作。
用处：SharedPtr = MakeShareable(ObjectPtr)，用于代替 TSharedPtr<XXX>、TSharedRef<XXX>

MakeShared，接收一堆对象构造函数的参数，调用 NewIntrusiveReferenceController，创建 TIntrusiveReferenceController

• 这个类继承自 TReferenceControllerBase，内部存有一个 TTypeCompatibleBytes，这个模板类会在特化的时候，知道自己应该占用的内存和对齐方式：

mutable TTypeCompatibleBytes<ObjectType> ObjectStorage;

template<typename ElementType>
struct TTypeCompatibleBytes
{
	using ElementTypeAlias_NatVisHelper = ElementType;
	ElementType*		GetTypedPtr()		{ return (ElementType*)this;  }
	const ElementType*	GetTypedPtr() const	{ return (const ElementType*)this; }

	alignas(ElementType) uint8 Pad[sizeof(ElementType)];
};

• 借此，就可以做到一次 new 操作，分配好 TReferenceControllerBase 和对象的内存

template <typename... ArgTypes>
explicit TIntrusiveReferenceController(ArgTypes&&... Args)
{
	new ((void*)&ObjectStorage) ObjectType(Forward<ArgTypes>(Args)...);
}

• 然后用 TIntrusiveReferenceController 和内部创建的 Object 用于创建 TSharedRef

FORCEINLINE explicit TSharedRef(ObjectType* InObject, SharedPointerInternals::TReferenceControllerBase<Mode>* InSharedReferenceCount)
	: Object(InObject)
	, SharedReferenceCount(InSharedReferenceCount)
{
	UE_TSHAREDPTR_STATIC_ASSERT_VALID_MODE(ObjectType, Mode)

	Init(InObject);
}

• 这样子就减少了一个内存碎片，并且引用控制器和对象的内存是也连续的

线程安全的实现

详细可参考：atomic原子编程中的Memory Order

SharedReferenceCount 和 WeakReferenceCount 会根据是否线程安全，特化成 std::atomic<int32> 或 int32。前者通过调用 fetch_add、fetch_sub 实现自增自减。

另外，简单提一下，线程安全判断的 if 后面使用了 constexpr，是因为这里的 Mode 是什么在模板特化后就知道了，所以这里的 if 走哪个分支在编译期就能确定结果，所以只需要编译目标分支即可。

std::atomic<int>，多线程操作共享资源时，编译器保证了操作的原子性，即任意时刻只有一个线程可以访问该资源。内核对象（事件对象（Event）、互斥量对象（Mutex）、信号量对象（Semaphore）等）会造成上下文切换，导致昂贵的开销（用户态切换到内核态，占用1000个以上的 cpu 周期）。

编译器和 CPU 可能对要执行的原子操作指令进行重排，在操作的函数内需要传递一个 memory_order 类型，定义当前操作的排序限制。

• memory_order_relaxed 表示随意排序；
• memory_order_consume 表示后面依赖此原子变量的访存指令，不能排到前面去，性能优于 memory_order_acquire；
• memory_order_acquire 表示后面访存指令，不能排到前面去；
• memory_order_release 表示前面访存指令，不能排到后面去；
• memory_order_acq_rel 为 acquire + release；
• memory_order_seq_cst 在 memory_order_acq_rel 的基础上，所有 seq_cst 指令之间的排序不能调动。

AddSharedReference 和 AddWeakReference 都是 memory_order_relaxed，而 ReleaseSharedReference 和 ReleaseWeakReference 则是 memory_order_acq_rel。

• 前者用 memory_order_relaxed 是因为所有的 Add 操作，任意交换指令顺序没什么问题，这个系统内部也没有其它地方会调用这里。
• 后者用 memory_order_acq_rel 是因为 Sub 操作需要保证代码顺序在这之前的，执行顺序需要在前，之后的需要保证在后面。例如 Add、Sub 调换顺序让原来没有销毁的情况现在销毁了，Sub、Add 调换顺序让原来销毁的情况现在不销毁了。

TUniquePtr

TUniquePtr 就比较简单了，因为不能共享，只能转移，自己没了资源也就没了，但是其可以支持对象数组。其继承自 Deleter，例如 TUniquePtr<ObjType, DeleterType>，那么该特化模板类的基类就是 DeleterType。有一个默认 Deleter 的偏特化版本是 Deleter = TDefaultDelete<T>，其销毁函数如下：

void operator()(T* Ptr) const
	delete Ptr;

TUniquePtr 用的销毁对象的方式就是 GetDeleter()(Ptr)、GetDeleter：static_cast<Deleter&>(*this)

TUniquePtr 是可以支持数组的，可以通过 MakeUnique 进行创建，例如 TUniquePtr<MyStruct[]> P = MakeUnique<MyStruct[]>(Number)；或者直接使用 TUniquePtr<MyStruct[]> P(new MyStruct[Number])

• MakeUnique：TEnableIf<TIsUnboundedArray<T>::Value, TUniquePtr<T>>::Type 在定义的 T 为 T[] 的情况下才能特化，即只有定义 TUniquePtr<XX[]> 时，才能使用该函数
  对于默认的 TDefaultDelete，有一个数组的偏特化版本 struct TDefaultDelete<T[]>，其 Delete 函数为 delete [] Ptr，以对所有的对象都调用析构函数。

顺便说下，delete[] 需要调用几个对象的析构函数，是存在首地址前面的 4 个字节内的