大规模itertools product场景下ThreadPool内存高效实现与优化问题

• 最高优先级问题：你代码中使用queue.deque(workers.imap_unordered(...))的写法，会将迭代器返回的所有结果（共1430万条，哪怕每条是None）全部存入deque对象中，直到迭代完全部任务后deque才会被销毁，这是内存飙升的核心原因，你误以为deque会即时清理结果，实际刚好相反，它把所有返回值都暂存到了内存里。
• 次要问题：你处理的是CPU密集型任务，使用multiprocessing.pool.ThreadPool（线程池）无法绕过GIL限制，根本不能实现多核加速，反而会增加调度开销，应该换成多进程Pool。
• 隐含问题：imap_unordered会按chunk size批量预读取输入迭代器的任务到内存中，不合理的chunk size会导致大量待处理任务积压在内存里。

1. 替换deque消费逻辑，直接迭代结果不存储：

# 错误写法，会累积所有返回值到deque
# queue.deque(workers.imap_unordered(...))

# 正确写法，迭代到的返回值直接丢弃，不累积
with multiprocessing.Pool(num_threads) as workers: # 注意这里换成多进程Pool，CPU密集场景才能提速
    for _ in workers.imap_unordered(functools.partial(dummy_func, keys=keys), 
                                    itertools.product(*map(parameters.get, keys)), 100):
        pass

修改后内存占用会直接降到和单进程版本接近的30MB左右水平。
2. 动态调整chunk size：如果后续任务逻辑变重，可以在10~1000区间调整chunk size，平衡内存占用和调度开销：

• chunk size越小，预加载到内存的待处理任务越少，内存占用越低，但调度开销越高
• chunk size越大，调度开销越低，但内存占用越高

3. 极端场景下可自己实现任务分块：手动按批次生成itertools.product的组合，处理完一批再生成下一批，完全控制内存上限。

chunk size指的是线程/进程池每次从输入迭代器（也就是你的itertools.product）批量拉取的任务数量：

• 不设置chunk size时，默认值为「总任务数/工作进程数」，你的场景总任务1430万，12核的话默认chunk size约为120万，一次就会把120万条组合预加载到内存，所以内存会涨到5GB以上
• 设置固定chunk size后，每次只会拉取对应数量的任务到内存，所以内存会稳定在一个较低水平，你之前因为有deque累积结果的问题，所以修改chunk size没有降到预期值，修复deque问题后，chunk size越小内存占用越低。

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