浅谈chromium中的指针管理
目录(?)[+]
前言
在大型C++系统中对指针的管理通常至关重要，这跟对象的生命周期相关，存在如下方面的考虑：
- 如何确保指针所指向的对象是在适当范围内是始终存在的？
- 如何构建一种机制，确保能正确检测指针所指向对象是否有效？
在chromium中对这类问题分别采用智能指针Scoped_refptr和弱指针WeakPtr来实现。
Scoped_refptr
Scoped_refptr 在智能指针scoped_ptr基础之上增加了引用计数功能，但尤其需要注意的是，引用计数的功能并不是由scoped_refptr提供的，而是由scoped_refptr对象本身提供的，也就说使用scoped_refptr的对象必须具备引用计数功能。Chromium中的引用计数功能由RefCouneted类提供，获取引用计数功能可以如下定义该类：
Class MyClass ： public RefCounted { ….}
Scoped_refptr 实现大致如下：
- 重载了*、-> 操作符，使之具备指针一样的功能，即像使用指针一样的使用Scoped_refptr对象，但Scoped_refptr对象一般在在栈中分配，在其作用域外自动释放；
- 重载了 = 赋值运算符，这样确保每次scoped_refptr 的每次传递、或者其所指对象被赋值给新的scoped_refptr对象时都能导致计数加1；
- 一般来说scoped_refptr 所包含的对象初始引用计数为0；但将其放入scoped_refptr时会导致引用计数+1；
- Release()函数代表所有权的转移；即scoped_refptr里保存的对象指针被赋值为NULL；返回对象指向的引用计数维持不变；
- 引用计数为0是删除scoped_refptr所包含的对象
Chromium 中Scoped_refptr使用场景一般为明确为某一线程所拥有的对象、或者某一类聚合的另一个类。对于跨线程使用的对象场合，一般使用弱指针。
Weakptr
在chromium的多线程模型里，对象通常被不同的线程访问，这就牵涉到线程同步问题；传统方法采用锁机制，关于锁机制的优劣参见Chrome源码剖析。 chromium的多线程模型实现的一个基本原则是：尽量规避锁；采取的策略则是task机制。见下图：
假设如下场景，A线程需要B线程做一些事情，然后回到A线程继续做一些事情；在chromium下你可以这样来做：生成一个Task，放到B线程的队列中，在该Task的Run方法最后，会生成另一个Task，这个Task会放回到A的线程队列，由A来执行。在该模型中一个最核心的问题就是task传递、运行过程中所涉及的对象、数据的安全性问题。在考虑上述的场景，线程A委托给线程B task1 ，task1运行需要访问对象object1；同样，线程B委托给线程A task2，task2 需要访问对象object2. 由于线程都采用消息队列机制，即轮询task队列方式实现。这就可能存在如下问题：
- 线程B 运行 task1时 object1已经被其他线程销毁；
- 线程A运行task2是 object2已经被其他线程销毁；
这里你可以说如果我使用引用计数机制，确保object1和object2都不会被销毁当然可以解决问题。但更多的情况下我们可能需要的另一种情况，即取消task1、task2的运行。例如UI线程委托IO线程下载某个资源时，用户刷新了当前网页，显然这时IO线程的下载task应取消。这个问题的核心就是：如何构建一种机制，确保能正确监测指针所指向对象是否有效；也就是如果其实线程B检测到Object1已经无效了，则自动取消task1的运行。这实质也是weakptr 弱指针的所需要解决的问题。
在谈论weakptr之前，我们先来探讨现实中一般如何解决这类问题。如果这个时候，存在一个第三方认证机构C，A和B能够通过向机构C来查询获取某个object的状态来确定是否执行某个task，这样问题就既然就得以解决了。实质上，这也是weakptr所采取的方法。先看weakptr的定义：
Template
Class Weakptr : public internal::WeakPtrBase {
// …….
T* ptr；
}；
Class WeakPtrBase {
Protected：
WeakReference ref_;
}
显然WeakPtr 弱指针除了包括所指对象的指针外，还包括一个额外的弱应用 WeakReference ref_。ref_可以看作是对第三方机构C的引用，即通过判断ref_是否有效来判定WeakPtr所保存的指针ptr是否有效。下面是WeakReference的定义：
class WeakReference {
public:
class Flag : public RefCounted, public NonThreadSafe {
public:
Flag(Flag** handle);
~Flag();
void AddRef() const;
void Release() const;
void Invalidate() { handle_ = NULL; }
bool is_valid() const { return handle_ != NULL; }
void DetachFromThread() { NonThreadSafe::DetachFromThread(); }
private:
Flag** handle_;
};
WeakReference();
WeakReference(Flag* flag);
~WeakReference();
bool is_valid() const;
private:
scoped_refptr flag_;
}
由上面定义可知有效性的检测实质由WeakReference内的Flag对象提供。接下来问题就是第三方机构C如何建立？ WeakReference ref_ 又如何使用它呢？这牵涉到类WeakReferenceOwner和WeakPtrFactory。 这里有一个事实应首先清楚：在上面的场景中 Object1可能被task1所使用、也可能被task2、… taskN所使用，而且这些task可能还在不同的线程中运行。因此为确保所有线程运行这些task时都能检测到Object1是否有效，显然这里要求WeakReference ref_ 所实质引用的对象是同一个，而且要确保该对象的生命周期可能长于Object1，即Object1被销毁了它还存在。 类WeakReferenceOwner 顾名思义，是WeakReference的owner，即它用于保证所有相关WeakPtr 中WeakReference ref_引用的是同一个对象，具体到Chromium中即为同一个Flag对象。见WeakReferenceOwner::GetRef()的实现：
WeakReference WeakReferenceOwner::GetRef() const {
if (!flag_)
flag_ = new WeakReference::Flag(&flag_);
return WeakReference(flag_);
}
接下来的问题就是如何创建WeakPtr对象，显然这里应有如下两个需求：
- 创建出来的WeakPtr跟实质所包含的对象是相关的，即设置ptr指针；
- WeakReference ref_ 最终所引用的flag 是同一个。
这通过WeakPtrFactory 实现，WeakPtrFactory用于创建某个Object的Weakptr，定义如下：
template
class WeakPtrFactory {
public:
explicit WeakPtrFactory(T* ptr) : ptr_(ptr) {
}
WeakPtr GetWeakPtr() {
return WeakPtr(weak_reference_owner_.GetRef(), ptr_);
}
// Call this method to invalidate all existing weak pointers.
void InvalidateWeakPtrs() {
weak_reference_owner_.Invalidate();
}
// Call this method to determine if any weak pointers exist.
bool HasWeakPtrs() const {
return weak_reference_owner_.HasRefs();
}
private:
internal::WeakReferenceOwner weak_reference_owner_;
T* ptr_;
DISALLOW_IMPLICIT_CONSTRUCTORS(WeakPtrFactory);
}
WeakPtrFactory 聚合了WeakReferenceOwner，用于保证指向同一个Flag。对于WeakPtrFactory的使用，可以在相关Object中聚合一个该WeakPtrFactory，这样可以直接通过Object的某个方法来获取其WeakPtr对象，例如：
Object1->weakptrfactory()->GetWeakPtr();
同时在Object的析构函数中调用WeakPtrFactory的InvalidateWeakPtrs函数，来使其Flag无效，最终供WeakPtr使用者检测其有效性。 对于另一个问题，如何确保所有WeakReference ref_ 所引用的Flag对象的生命周期长于Object本身，即Object销毁时它仍然存在，直到所有的WeakReference ref_都销毁时。显然，从Flag的定义可以看出，采用引用计数方式即可。关于WeakPtr的关系见下图：