array模块不支持并发，仅适用于单线程下紧凑存储同类型数值；高并发时应使用multiprocessing.Array、memoryview或对象池等方案。
array 模块本身不支持并发，也不能直接优化“高并发”场景的内存占用——它只提供紧凑、同类型数值序列的内存布局，适合单线程下降低内存开销。如果你正面临多线程/异步环境下大量数值数据导致的内存暴涨，array 可能被误用，先厘清这点很关键。
为什么 array 在高并发中常被误认为“能优化”
常见误解是：既然 array.array('d', [...]) 比 list[float] 内存小 3–4 倍，那在多线程写入时也能省资源。但问题在于：array 对象不是线程安全的，且无法原子更新任意索引——多个线程同时调用 append() 或写 a[i] = x 会触发 RuntimeError: array index out of range 或静默数据错乱。
array 的真实适用场景和初始化要点
它只应在以下情况使用：
- 数据类型固定（如全是
int或float），且长度已知或可预估 - 生命周期集中于单一线程内（例如：IO 线程读取二进制流后批量转为
array，再交由计算线程只读处理） - 需与 C 扩展（如 NumPy、Cython）交互，或写入
memoryview避免拷贝
初始化建议用 array.array(typecode, iterable) 一次性构造，而非循环 append ——后者在 Python 3.12 中仍会触发多次 realloc，反而增加碎片。例如：
# 推荐：一次分配
data = array.array('d', (x * 0.1 for x in range(1000000)))
<h1>不推荐：隐式扩容 + GIL 持有时间拉长</h1><p>data = array.array('d')
for x in range(1000000):
data.append(x * 0.1) # 每次 append 都要检查容量、可能 realloc
</p>
真正影响高并发内存的关键点
当并发任务产生大量中间数值数据时，内存压力通常来自：
- 每个线程持有一份独立
list或array→ 改用对象池或预分配共享缓冲区（如threading.local()+ 固定大小array复用） - 异步任务返回未及时 await 或未释放引用 → 导致
array实例无法 gc（尤其含大 buffer 时） - 错误地将
array当作线程间通信载体 → 应改用queue.Queue或multiprocessing.Array（后者才是进程安全的共享数组）
Python 3.12 中，array 的底层实现没变，但 GC 对大 buffer 的回收更敏感；若你看到 array 实例长期驻留，大概率是外部强引用未清理，而不是 array 本身有问题。
替代方案比硬套 array 更有效
如果目标是“高并发 + 低内存”，优先考虑：
- 用
memoryview包装已有array或bytes，避免切片拷贝 - 对 IO 密集型任务，用
asyncio.StreamReader.readexactly(n)直接读进预分配的bytearray，再用memoryview(...).cast('d')解析 - 跨进程场景必须用
multiprocessing.Array('d', size)，它背后是共享内存，且 Python 3.12 已修复其在 macOS 上的 mmap 对齐 bug
别指望靠换容器解决并发模型缺陷；array 是螺丝刀，不是起重机——用错地方，拧得越用力，崩得越快。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
