Python并发资源回收需主动管理：线程/进程内用try...finally或with显式释放；asyncio协程须用async context manager；多进程共享资源依赖Manager统一托管，需显式shutdown；weakref可辅助但不能替代主动清理。
Python中的并发资源回收与生命周期管理，核心在于理解对象何时被创建、何时被使用、何时该被释放——尤其在多线程、多进程或异步任务中，资源（如文件句柄、数据库连接、锁、线程局部存储等）若未及时清理，易引发泄漏、阻塞或状态不一致。
线程/进程内资源的生命周期由作用域和显式释放共同决定
线程局部变量（threading.local()）或进程内单例对象，其生命周期绑定于线程/进程的存活期。但Python不保证线程退出时自动调用__del__或触发垃圾回收，因此依赖__del__做清理不可靠。
- 推荐在
try...finally块中显式释放，例如关闭文件、释放锁、断开连接 - 使用上下文管理器（
with语句）是最安全的方式，确保进入和退出逻辑成对执行 - 避免在线程函数中长期持有大对象或全局引用，防止线程结束后对象仍被间接引用而无法回收
asyncio协程中资源需配合async context manager或生命周期钩子
普通__enter__/__exit__不支持await，必须使用__aenter__/__aexit__实现异步上下文管理器。例如异步数据库连接池、HTTP会话等，应在__aexit__中await关闭操作。
- 不要在协程中直接用
time.sleep()代替asyncio.sleep()，否则阻塞事件循环，拖慢整个资源调度节奏 - 协程函数返回后，若仍有pending task引用资源（如未await的Future），该资源可能延迟释放
- 可借助
asyncio.create_task()+asyncio.shield()控制清理时机，避免任务被意外取消导致清理中断
多进程间共享资源要警惕引用计数与序列化开销
通过multiprocessing.Manager()或Value/Array共享的数据，底层依赖进程间通信（IPC）机制。这些对象的生命周期不由单个进程控制，而是由Manager进程统一托管。
立即学习“Python免费学习笔记（深入）”；
- Manager启动的子进程不随主进程退出自动终止，需显式调用
manager.shutdown() - 传递给子进程的不可序列化对象（如lambda、嵌套闭包）会引发
PicklingError，间接导致资源初始化失败或静默跳过 - 频繁跨进程访问共享对象会产生较大IPC开销，应尽量减少粒度，改用批量读写或本地缓存+定期同步
GC与弱引用可辅助但不能替代主动管理
Python的循环垃圾回收器（GC）能处理引用环，但无法感知“逻辑上已废弃但技术上仍有引用”的资源（如缓存中过期的连接）。此时可用weakref避免强引用阻碍回收。
-
weakref.finalize(obj, callback)适合注册轻量级清理回调，注意callback不能强引用obj本身 - 对缓存类结构（如LRU cache），建议结合
weakref.WeakValueDictionary或手动维护有效期+定时清理 - 启用
gc.set_debug(gc.DEBUG_UNCOLLECTABLE)有助于发现无法回收的循环引用，但生产环境慎用，有性能损耗
不复杂但容易忽略。关键不是等Python来收，而是清楚每个资源谁创建、谁负责关、在哪个环节关最稳妥。
