对象池仅在构造开销大、生命周期可控、状态可重置时才适用；单次构造＞10μs且每秒创建＞1k次是硬指标；宜用queue.LifoQueue实现，注意预热、显式重置与线程安全。
对象池不是万能解药，盲目套用反而增加 GC 压力和线程同步开销；它只在满足「构造开销大 + 生命周期可控 + 状态可重置」三个条件时才值得引入。
什么时候该用对象池，而不是直接 new
对象池本质是空间换时间：预分配一批实例，用完不销毁，而是清空状态后放回池中待复用。但前提是——这个“清空”要快，且不会残留副作用。
- 适合场景：
re.Pattern编译后反复匹配、xml.etree.ElementTree.Parser解析器、自定义的Buffer或Message类（含固定结构 + 可.reset()） - 不适合场景：带闭包/回调函数的对象、依赖
__del__清理资源的类、状态强耦合无法安全重置的实例 - 一个硬指标：单次构造耗时 > 10μs，且每秒创建频次 > 1k 次，才值得考虑池化
用 queue.LifoQueue 实现轻量对象池
不用第三方库，标准库 queue.LifoQueue 就够用——LIFO 比 FIFO 更贴近局部性原理，缓存行命中率更高。
- 池初始化时预热：提前生成 4–8 个实例（太少起不到缓冲作用，太多浪费内存）
- 获取对象：用
pool.get_nowait()，失败则 fallback 到MyClass()新建（避免阻塞） - 归还对象：必须在业务逻辑结束后显式调用
.reset()或.clear()，再pool.put_nowait(obj) - 注意：多线程下需确保
.reset()是线程安全的；若对象含锁或文件句柄，池化前先解耦资源管理
避免对象池反模式
常见错误不是“没用池”，而是“用错了池”。以下行为会抵消甚至逆转收益：
- 池大小设为
maxsize=0（无限大）：内存持续增长，GC 频繁触发，比不用还慢 - 归还前未清理引用：比如
obj._cache = {}没清，导致旧数据残留，引发隐蔽 bug - 把
threading.local()当池用：每个线程独占实例，失去复用意义，还增加 TLS 查找开销 - 在异步协程里混用同步队列：用
asyncio.Queue替代queue.LifoQueue，否则会阻塞 event loop
对比 __slots__ 和对象池的适用边界
__slots__ 降低的是单个对象的内存 footprint，对象池降低的是构造/销毁频率。两者不互斥，但解决的问题维度不同。
- 你有一百万个
Point(x, y)实例？优先加__slots__ = ('x', 'y')，省内存比省构造更直接 - 你每秒新建 5000 个
HTTPSession并立即丢弃？这时才轮到对象池上场，且要配合连接复用（keep-alive） - 最常被忽略的一点：池中对象的
__init__仍会被调用一次（预热时），所以池本身不能替代对构造逻辑的优化（比如把正则编译提到类外）
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
