使用boto3监听SQS时垃圾回收异常，内存累积求助

这种gc.garbage随迭代次数持续增长、内存不断累积的情况绝对不是正常现象，说明你的代码或者依赖库存在未正确释放的引用，导致Python垃圾回收机制无法清理这些不可达对象。下面是具体的原因分析和排查方向：

可能的原因 #

1. 带__del__方法的循环引用对象 #

Python的垃圾回收器无法自动处理带有__del__方法的循环引用对象，这类对象会被移至gc.garbage列表中，无法被回收。如果你的SQS消息处理逻辑中存在自定义类实例形成循环引用，同时定义了__del__方法，就会触发这个问题。

示例场景：

class MessageProcessor:
    def __init__(self):
        self.related_processor = None
    def __del__(self):
        # 自定义析构逻辑
        pass

# 形成循环引用
processor_a = MessageProcessor()
processor_b = MessageProcessor()
processor_a.related_processor = processor_b
processor_b.related_processor = processor_a

2. 第三方库的资源泄漏 #

如果使用的SQS SDK（如boto3）在使用过程中存在资源未正确释放的情况，或者内部实现存在循环引用+__del__的问题，也会导致对象无法被回收。比如：

• 每次迭代都新建SDK客户端实例，未复用导致大量对象残留
• 请求/响应对象被全局变量、闭包或其他长期存在的对象意外持有引用

3. 线程局部存储（TLS）残留引用 #

由于代码在独立线程的无限循环中运行，如果使用了threading.local()存储对象，但每次迭代后未清理TLS中的无用数据，这些对象会被线程持有，无法被GC回收。

排查与修复步骤 #

1. 定位未回收对象的类型与引用链 #

通过打印gc.garbage中对象的类型和引用关系，精准定位问题根源：

import gc

# 在每次gc.collect()后执行
gc.collect()
if gc.garbage:
    print(f"当前未回收对象数量: {len(gc.garbage)}")
    for idx, obj in enumerate(gc.garbage[:5]):  # 打印前5个避免输出过多
        print(f"\n对象{idx+1}类型: {type(obj)}")
        print(f"引用该对象的实例: {gc.get_referrers(obj)}")
        print(f"该对象引用的实例: {gc.get_referents(obj)}")

2. 移除自定义__del__方法测试 #

如果排查到是带__del__的循环引用对象，先临时移除__del__方法，重新运行代码。若gc.garbage停止增长，说明问题源于此。此时可以：

• 使用weakref弱引用替代强引用，打破循环
• 重新设计对象关系，避免循环引用

3. 规范第三方库的使用 #

• 复用SDK客户端实例（如boto3的client或resource），不要在循环内重复创建
• 确保处理完消息后，及时清理与当前请求相关的变量，避免被全局对象持有

4. 清理线程局部存储 #

如果使用了threading.local()，在每次迭代结束时手动清理无用数据：

import threading

thread_local = threading.local()

# 迭代结束后清理
if hasattr(thread_local, 'temp_data'):
    del thread_local.temp_data

内容的提问来源于stack exchange，提问作者deadshot