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的观察者，即回调通知函数，下面大家看个例子：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 |
# -*- coding: utf-8 -*- import weakref class Container: def __init__(self): self.dict = {} def add(self, obj): # 维护弱引用, 实现gc回调 self.dict[weakref.ref(obj, self.gc)] = id(obj) def gc(self, ref_obj): obj_id = self.dict[ref_obj] print("移除object id:", obj_id, "weakref对象:", ref_obj, "指向的对象:", ref_obj()) del self.dict[ref_obj] class SomeCls: pass # 容器 container = Container() # 任意对象 obj1 = SomeCls() obj2 = SomeCls() # 加入容器 container.add(obj1) container.add(obj2) # 释放对象 del obj2 del obj1 |
代码输出：
|
1 2 |
移除object id: 4351353968 weakref对象: <weakref at 0x1035c4598; dead> 指向的对象: None 移除object id: 4351353800 weakref对象: <weakref at 0x1035c4548; dead> 指向的对象: None |
容器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归还到池子中。
如果文章帮助您解决了工作难题，您可以帮我点击屏幕上的任意广告，或者赞助少量费用来支持我的持续创作，谢谢~
