python弱引用的真正用法

弱引用在很多语言中都存在,最常用来解决循环引用问题,我个人熟悉C++的版本。

在本文,我们讲一下python中的weakref弱引用,因为我发现网上没有人把这个东西讲明白,要么是千篇一律解决循环引用,要么是长篇大论各种demo,着实让人头疼。

观察者模式

弱引用是观察者模式,A持有B的弱引用,那么不会对B增加引用计数。

当B引用计数为0之后,A尝试通过弱引用访问B就会失败,因为弱引用对象是观察者,观察着B对象的引用计数。

不同的编程语言实现弱引用的底层原理略有不同,但本质都是观察者模式。

深度解读

下面以C++为例,其实一个对象的引用计数是存储在对象之外的堆内存中的,下面请紧跟我的思路。

A对象在私有属性保存着refcount*指针,refcount*保存真正的引用计数N,初始化N=1。

当另一处代码想要获取A对象的引用时,调用A->refcount->addRef()令N=N+1,即可增加1个引用计数,确保自己访问A对象期间,内存不会释放。

同样的,释放A引用调用A->refcount->delRef()令N=N-1即可释放自己持有的引用,当N减少为0的时候说明A对象没有人持有,可以释放资源。

总结一下,维护引用计数的是refcount*,而不是A。

当我们创建一个指向A的weakref对象时,它要做的是观察A对象的引用计数,所以weakref对象会将A->refcount*保存在自己的私有属性里。

这时候,refcount对象出现了多处引用的共享问题,所以refcount对象自身也需要引用计数。

refcount有另外一个属性M记录自身被引用的次数,而不是A被引用的次数。

当A创建时M=1,因为只有A保存了refcount;当weakref观察A时,weakref会将A->refcount赋值给自己的私有属性,所以refcount的M=M+1,也就是2。

当A对象的引用计数N减少为0后,A会释放自己,所以也释放了对A->refcount的1个引用计数,此时M=M-1,还剩余1是weakref持有的。

此时weakref可以检查refcount的N=0,即可获知A已经被释放。

当weakref自身释放时,会令weakref->refcount的M=M-1,即M减少为0,此时refcount对象已无人持有,也会被释放。

Python中的weakref

Python的weakref最强的一点,在于其观察者模式可以主动回调。

也就是说,当A对象N=0后,python可以主动通知持有weakref的观察者,即回调通知函数,下面大家看个例子:

代码输出:

容器Conainter:

  • 只维护对象的weakref,并且当对象refcount为0后,会回调container.gc方法。
  • 在gc方法中,把相关的上下文删除掉,其实也就是释放weakref对象自身的内存资源。

python回调时,会传入关联的weakref对象,我们利用weakref()可以获得观察的真实对象,但在gc中一定会返回None,因为对象已经被回收。

用途

理解weakref后,就可以拿来实现一些连接池之类的东西。

比如Conainter是mysql连接池,内部维护了20个mysql连接,然后提供get/put方法来获取connection和归还connection。

那么作为一个工具库提供者,最害怕的就是使用者忘记put归还连接,如何妥善应对这群傻瓜用户呢?最简单的思路就是,当使用者不再持有connection对象后,我们主动把连接回收到连接池中,也就是我们如何知道使用者搞完了?

想办法套用weakref的callback机制!

既然weakref是观察者,那么要观察的就是connection。

但是底层connection对象在Container里本身就维护了一份引用,直接给使用者的话,refcount永远不可能减少为0。

所以,Container返回给使用者的应该是一个WrappedConnection对象,里面装着底层Connection,然后Container额外维护一个WrappedConnection的weakref即可。

当WrappedConnection对象不再被使用者持有后,weakref会回调Container,那么Container就可以把weakref对应的底层Connection归还到池子中。

 

 

发表评论

电子邮件地址不会被公开。