Python2.7逐行读取大基因组文件时内存占用异常过高的问题

首先得明确你遇到的核心问题：虽然你用了逐行读取的方式，但最终还是把所有数据都存在了posList（或者后续的字典）里，这才是内存爆炸的根源，而且sys.getsizeof()的结果很有迷惑性，下面一步步拆解：

为什么内存占用远高于预期？ #

1. sys.getsizeof()的误区 #

sys.getsizeof(posList)只计算列表对象本身的内存开销（比如存储元素指针的空间），完全不包含列表中每个字符串的内存占用！Python的字符串对象本身有额外开销（对象头、哈希值、长度等），加上磁盘上的文本字节在内存中会被转成Python字符串对象，实际内存占用会比磁盘文件大很多。比如你17GB的文件生成的字符串列表，实际内存占用远不止5GB，再加上Python解释器的开销、内存碎片，top显示43GB就很合理了。

2. 四个脚本的本质问题 #

你的四个脚本看起来是不同的读取方式，但核心逻辑都是把所有行读取后存在posList里，所以内存占用不会有本质区别：

• Script1（itertools）：iter(f)和直接for line in f完全等价，因为Python文件对象本身就是迭代器，没有任何额外优势。
• Script2（fileinput）：适合批量处理多个文件，单文件场景下和Script3没有区别。
• Script3（for line in f）：这是Python读取文本大文件的标准最优方式，读取逻辑没问题，问题出在存储所有行。
• Script4（yield按chunk读）：这是错误的用法！chunkSize=30会把完整的行截断成小块，生成大量不完整的字符串，反而会因为更多小对象增加内存开销，完全不适合处理按行组织的文本文件。

3. 业务场景的内存压力 #

你的实际需求是生成一个存储所有位点碱基的字典，再用pileup文件更新。如果是人类基因组这种量级（~30亿位点），用Python原生字典存储每个位点的键值对，内存开销会极其巨大——每个键（位点标识）和值（碱基）都是字符串对象，每个键值对的内存开销可能超过100字节，30亿个就是300GB以上，完全不可能放在内存里。

优化方案：从存储策略入手 #

既然读取方式没问题，核心要解决的是不要把所有数据放在内存里，或者用更紧凑的存储结构，以下是针对你业务场景的具体建议：

方案1：基于磁盘的存储（推荐） #

用数据库或者临时文件代替内存字典，只处理当前行的数据：

• 用sqlite3轻量数据库：
  1. 读取FASTA文件时，批量插入位点数据，初始值设为'N'；
  2. 读取pileup文件时，逐行更新数据库中对应位点的碱基值；
  3. 所有处理完成后，再从数据库导出结果。
     这种方式内存只需要处理当前行，完全不会有内存爆炸的问题。

方案2：用紧凑的数据结构代替字典 #

如果必须把数据放在内存里，用更高效的存储方式：

• 用numpy数组：把碱基映射成整数（比如N=0, A=1, T=2, C=3, G=4），用numpy.uint8数组存储，每个元素只占1字节。比如30亿个位点只需要3GB左右的内存，远小于字典的开销。
• 用array模块：和numpy类似，原生Python的array.array可以存储紧凑的数值类型，内存占用比列表小很多。

方案3：分块处理基因组 #

把基因组按染色体或者固定区域分成小块，每次只处理一个块：

1. 读取FASTA文件中某条染色体的位点，生成小字典/数组；
2. 读取pileup文件中对应染色体的行，更新该块的数据；
3. 处理完后把该块的结果写入文件，释放内存，再处理下一个块。

方案4：边处理边输出（如果不需要全量存储） #

如果你的任务不需要最终保存全量字典，而是可以边处理边输出结果，那完全不需要把所有数据存在内存里：读取一行pileup，更新对应位点（如果不需要保留所有位点，甚至可以只处理当前行就输出），处理完就丢弃，内存只保留当前行的信息。

总结 #

你的问题不在文件读取方式，而在全量数据内存存储。只要改变存储策略，要么用磁盘存储代替内存，要么用紧凑数据结构，要么分块处理，就能解决内存占用过高的问题。

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