Python怎样实现内存优化？__slots__使用技巧-Python教程-PHP中文网

使用__slots__能有效减少python对象内存占用，特别是在创建大量小对象时。1. __slots__通过禁止实例创建__dict__，将属性存储于固定内存空间，从而降低每个实例的内存开销；2. 在继承中，子类必须也定义__slots__才能避免生成__dict__，否则无法享受内存优化；3. 多重继承时若任一父类未定义__slots__，子类将被迫拥有__dict__；4. 使用__slots__后无法动态添加属性，且默认不支持弱引用，需显式添加'__weakref__'；5. 调试困难、序列化兼容性风险及代码灵活性下降是其主要缺点，仅建议在内存压力大且对象数量庞大的场景使用。因此，__slots__是一种以牺牲灵活性换取内存效率的机制，适用于属性固定、实例众多的类，使用时需权衡利弊并谨慎设计继承结构。

Python怎样实现内存优化？__slots__使用技巧

Python要实现内存优化，特别是针对大量小对象时，

__slots__

登录后复制

绝对是一个值得深挖的利器。它并非万能药，但对于那些需要创建成千上万个结构相似、属性固定的对象场景，比如ORM模型实例、事件对象或者各种数据容器，

__slots__

登录后复制

能显著减少每个实例的内存占用，从而降低整体内存消耗，甚至在某些情况下还能略微提升属性访问速度。我个人觉得，这玩意儿就像是给你的Python对象做了一次“精简手术”，把不必要的脂肪（

__dict__

登录后复制

）给去掉了。

当你需要对Python应用的内存占用进行精细控制时，

__slots__

登录后复制

提供了一种直接且高效的途径。

如何利用

__slots__

登录后复制

进行内存优化

立即学习“Python免费学习笔记（深入）”；

说白了，Python对象默认是相当“胖”的。每个实例都有一个内置的

__dict__

登录后复制

字典，用来存储其所有实例属性。这个字典非常灵活，你可以随时往对象里添加新属性，但这同时也意味着每个实例都得维护一个哈希表，即便它只有一两个属性，这个哈希表也占着不小的空间。想象一下，如果你有100万个用户对象，每个对象都带一个臃肿的

__dict__

登录后复制

，那内存消耗就相当可观了。

__slots__

登录后复制

的原理就是绕过这个默认的

__dict__

登录后复制

机制。当你在一个类中定义了

__slots__

登录后复制

，并指定了它允许包含的属性名称时，Python就不再为这个类的实例创建

__dict__

登录后复制

了。取而代之的是，实例的属性会被存储在一个更紧凑的结构中，通常是固定大小的数组或元组，直接指向属性值。这就像是给对象分配了一块预设好的、刚好够用的空间，而不是一个可以无限扩容的大仓库。

import sys

# 普通类
class Point:
    def __init__(self, x, y):
        self.x = x
        self.y = y

# 使用__slots__的类
class SlottedPoint:
    __slots__ = ('x', 'y') # 明确指定允许的属性
    def __init__(self, x, y):
        self.x = x
        self.y = y

# 比较内存占用
p = Point(1, 2)
sp = SlottedPoint(1, 2)

print(f"普通Point对象内存占用: {sys.getsizeof(p)} 字节")
print(f"SlottedPoint对象内存占用: {sys.getsizeof(sp)} 字节")
# 还可以进一步查看__dict__是否存在
# print(p.__dict__) # 存在
# print(sp.__dict__) # 抛出AttributeError

登录后复制

从上面的例子就能直观地看出，

SlottedPoint

登录后复制

的实例内存占用会显著小于

Point

登录后复制

。因为

SlottedPoint

登录后复制

实例没有了

__dict__

登录后复制

这个“包袱”，它只为

登录后复制

和

登录后复制

属性分配了必要的空间。

__slots__

登录后复制

是如何减少内存占用的？

要理解

__slots__

登录后复制

为什么能省内存，我们得稍微深入一点看看Python对象的内部结构。每个Python对象，除了它自己的数据，还需要一些额外的开销，比如类型指针、引用计数等等。而当我们创建的类没有定义

__slots__

登录后复制

时，Python会为每个实例额外分配一个字典（

__dict__

登录后复制

）来存储实例变量。这个字典本身就是一个哈希表，即使它是空的，也会占用几十个字节。当你有属性时，这个字典会存储属性名（字符串）到属性值（对象引用）的映射。字符串和哈希表结构，都是内存消耗大户。

我记得有一次，在处理一个日志分析系统时，需要创建数百万个日志事件对象。刚开始没多想，直接就定义了普通的类。结果呢？内存蹭蹭地往上涨，服务器直接报警了。这时候，

__slots__

登录后复制

就成了我的救星。

使用

__slots__

登录后复制

后，实例的属性不再通过

__dict__

登录后复制

来存储，而是直接存储在对象本身的固定偏移量上。这就像是C语言中的结构体，每个成员都有一个固定的位置。这样一来，每个实例就省去了维护一个独立字典的开销，内存自然就下来了。对于那些属性固定、数量庞大的对象来说，这种优化带来的效果是立竿见影的。而且，由于属性访问不再需要哈希查找，理论上属性访问速度也会略有提升，尽管这个提升通常不如内存优化那么明显。

__slots__

登录后复制

在继承体系中如何工作？

__slots__

登录后复制

在继承体系中的行为，确实是它比较容易让人“踩坑”的地方。理解这一点至关重要，否则你可能以为自己优化了内存，结果却适得其反。

巧文书

巧文书是一款AI写标书、AI写方案的产品。通过自研的先进AI大模型，精准解析招标文件，智能生成投标内容。

查看详情

首先，一个基本原则是：如果子类也想享受到

__slots__

登录后复制

带来的内存优化，那么子类自身也必须定义
__slots__
登录后复制
。否则，即使父类使用了

__slots__

登录后复制

，子类实例也会默认拥有

__dict__

登录后复制

，从而失去内存优化的效果。

class BaseSlotted:
    __slots__ = ('base_attr',)
    def __init__(self, base_attr):
        self.base_attr = base_attr

class SubClassNoSlots(BaseSlotted):
    # 没有定义__slots__
    def __init__(self, base_attr, sub_attr):
        super().__init__(base_attr)
        self.sub_attr = sub_attr

class SubClassWithSlots(BaseSlotted):
    __slots__ = ('sub_attr',) # 子类也定义了__slots__
    def __init__(self, base_attr, sub_attr):
        super().__init__(base_attr)
        self.sub_attr = sub_attr

s1 = SubClassNoSlots(1, 2)
s2 = SubClassWithSlots(1, 2)

print(f"SubClassNoSlots实例是否有__dict__: {'__dict__' in dir(s1)}") # True
print(f"SubClassWithSlots实例是否有__dict__: {'__dict__' in dir(s2)}") # False (如果父类和子类的__slots__不冲突)
# 注意：如果子类__slots__中包含了父类__slots__中已有的属性名，是允许的，但不会重复分配空间。
# 如果子类__slots__中没有包含父类的属性，那父类的属性仍然是slots管理的。

登录后复制

其次，如果子类定义了

__slots__

登录后复制

，并且其父类也定义了

__slots__

登录后复制

，那么子类

__slots__

登录后复制

中定义的属性会添加到父类

__slots__

登录后复制

中定义的属性集合中。这意味着子类实例的属性将是父类和子类

__slots__

登录后复制

的并集。

一个更复杂的情况是多重继承。如果一个类继承自多个父类，并且这些父类中至少有一个没有定义

__slots__

登录后复制

，那么这个子类（即使它自己定义了

__slots__

登录后复制

）也必须拥有

__dict__

登录后复制

，因为Python需要兼容那个没有

__slots__

登录后复制

的父类的行为。同样地，如果多个父类都定义了

__slots__

登录后复制

，但它们的

__slots__

登录后复制

定义中包含了相同的属性名，并且这些属性名没有被正确地合并处理，也可能导致问题（尽管Python通常能处理这种情况，但最好避免）。

我个人建议，在设计继承体系时，如果打算使用

__slots__

登录后复制

，最好从基类就开始规划，并确保所有子类都遵循

__slots__

登录后复制

的约定。这样能避免很多不必要的麻烦和内存陷阱。

使用

__slots__

登录后复制

的实际考量与潜在陷阱

__slots__

登录后复制

虽然是内存优化的利器，但它并非没有代价。在实际项目中，我发现一些常见的“坑”和需要权衡的地方：

无法动态添加新属性： 这是
```
__slots__
```
登录后复制
最显著的限制。一旦你定义了
```
__slots__
```
登录后复制
，你就不能再给实例添加不在
```
__slots__
```
登录后复制
中列出的新属性了。比如，你不能写
```
my_object.new_property = 'value'
```
登录后复制
。这对于一些需要高度灵活、运行时可能需要给对象打“补丁”的场景来说，是个大问题。我曾遇到过同事在调试时，想临时给一个对象加个状态标记，结果因为
```
__slots__
```
登录后复制
直接报错，搞得一脸懵。
没有
```
__dict__
```
登录后复制
和
__weakref__
登录后复制
：由于
```
__slots__
```
登录后复制
禁用了
```
__dict__
```
登录后复制
，所以你不能再通过
```
vars(instance)
```
登录后复制
来查看实例的所有属性字典了。这在调试时会稍微不方便。此外，默认情况下，带有
```
__slots__
```
登录后复制
的实例不能被弱引用（
```
weakref
```
登录后复制
）。如果你需要对这些实例进行弱引用（例如，在缓存或循环引用场景），你必须显式地在
```
__slots__
```
登录后复制
中加入
```
'__weakref__'
```
登录后复制
。
继承复杂性： 前面已经提到了，继承体系中
```
__slots__
```
登录后复制
的行为需要仔细考量。如果父类没有
```
__slots__
```
登录后复制
，子类即使定义了，也无法完全消除
```
__dict__
```
登录后复制
。多重继承更是可能带来预料之外的行为。
序列化兼容性： 虽然
```
__slots__
```
登录后复制
不影响
```
pickle
```
登录后复制
等序列化操作，但如果你的类定义在序列化和反序列化之间发生了变化（比如增删了
```
__slots__
```
登录后复制
中的属性），可能会导致兼容性问题。
并非所有情况都值得：
```
__slots__
```
登录后复制
带来的代码复杂度和限制，只有在确实面临大量对象且内存成为瓶颈时才值得引入。对于只有少量实例的类，
```
__dict__
```
登录后复制
带来的额外内存开销几乎可以忽略不计，而为了那点微不足道的优化而牺牲代码的灵活性和可读性，我觉得是得不偿失的。我通常的经验是，只有当你的应用开始出现内存报警，或者性能分析明确指向对象内存占用过高时，才考虑
```
__slots__
```
登录后复制
。