在大型C++系统中对指针的管理通常至关重要,这跟对象的生命周期相关,存在如下方面的考虑:
在chromium中对这类问题分别采用智能指针Scoped_refptr和弱指针WeakPtr来实现。
Scoped_refptr 在智能指针scoped_ptr基础之上增加了引用计数功能,但尤其需要注意的是,引用计数的功能并不是由scoped_refptr提供的,而是由scoped_refptr对象本身提供的,也就说使用scoped_refptr的对象必须具备引用计数功能。Chromium中的引用计数功能由RefCouneted类提供,获取引用计数功能可以如下定义该类:
Class MyClass : public RefCounted { ….}
Scoped_refptr 实现大致如下:
Chromium 中Scoped_refptr使用场景一般为明确为某一线程所拥有的对象、或者某一类聚合的另一个类。对于跨线程使用的对象场合,一般使用弱指针。
在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队列方式实现。这就可能存在如下问题:
这里你可以说如果我使用引用计数机制,确保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对象,显然这里应有如下两个需求:
这通过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的关系见下图: