简介面向算法学习者与开发者的基于 Python 的并行遗传算法实现针对大规模优化问题计算耗时的痛点演示利用多进程或线程池将种群分割、并行执行选择与交叉变异的关键思路。包内共两个脚本文件涵盖主程序与算法核心模块整体仅约六千字节轻量易读适合快速上手。压缩包中包含两个脚本可对照理解串行遗传算法步骤与并行化改造方式。已有二百二十四人学习下载说明具备一定参考价值。示例代码可直接运行两个脚本均包含清晰注释便于理解关键逻辑。读者可获得可运行的并行遗传算法示例代码、种群初始化、适应度评价、选择、交叉、变异的标准流程以及负载均衡、数据同步等并行优化注意事项的代码化演示适合入门并行计算或遗传算法实践的开发者。1. 并行遗传算法GAPython里把优化提速的实用路径跑过遗传算法的人大概率经历过这种事函数写对了种群规模调到100代数放到200结果一跑就是一夜。稍微复杂一点的规划、调度或模型参数标定问题单次适应度评估就要几十毫秒串行版本整个进化过程慢到让人怀疑人生。并行遗传算法GA要解决的就是这个时间瓶颈——把个体评估拆到多进程里或者让多个种群各跑各的进化再定期交换个体。它不是换一个算法而是给遗传算法接上多核算力的管道。这篇文章写给两类人一类是写过串行GA、被性能卡住、想找个可靠并行方案的另一类是刚接触遗传算法希望一步到位、直接写并行版本的程序员。我会从并行模型的选择讲起用可复现的Python代码把主从模型和岛屿模型跑通再把几个让我翻过车的坑逐一拆开最后给出一套能说服自己也能说服团队的加速比验证方法。2. 并行GA的三条技术路线主从、岛屿、细粒度怎么选2.1 主从模型适应度评估是瓶颈时就选它主从模型是并行化遗传算法里改动最小、收益最直接的一种。主进程负责执行选择、交叉、变异这些遗传操作把这一代种群打包发给多个工作进程去计算适应度收齐结果后再继续下一代。整个算法的逻辑和串行版本几乎一致唯一变化就是把“循环计算每个个体的适应度”变成了“派发任务并回收结果”。选择主从模型的条件非常明确当适应度评估耗时占单代总耗时的一半以上时这个模型几乎是最优解。比如你用一个数值仿真器评估个体或者跑一个复杂的惩罚函数单次评估要几十毫秒到几秒那么评估环节就是明显的热点。并行化这一块收益能直接反映在墙钟时间上。需要特别说明的是Python里做这类CPU密集型并行不要用threading。Python的GIL锁决定了同一进程内多个线程无法真正并行执行Python字节码纯计算任务用线程反而会比串行更慢。我见过不少人拿着threading改三行就去测速结果发现并行GA比串行还慢这不是方案错是并发工具选错了。主从模型在Python里的正确落地方式是multiprocessing后面第三章会给出完整代码。2.2 岛屿模型解决早熟收敛顺带真正并行岛屿模型和主从模型的思路完全不同。它不把单个种群拆开而是同时维护多个相对独立的子种群每个子种群像一座岛一样独立进化每隔若干代把各自的精英个体迁移给相邻的岛。这样做有两个好处一是多个种群天然并行二是迁移机制能显著缓解遗传算法最常见的早熟收敛问题。遗传算法在单一种群里一旦某个较优个体通过选择迅速扩散整个种群的多样性就会下降后续很难跳脱局部最优。而岛屿模型里每个岛的进化方向可能各不相同一个岛陷入局部最优时其他岛可能还在更广阔的区域搜索。通过迁移那些携带不同基因的个体会被引入相当于给陷入停滞的岛注入了新的进化动力。岛屿模型需要关注三个参数迁移周期每隔多少代迁移一次、迁移率每次迁出多少个个体和迁移拓扑岛与岛之间的连接关系。这三个参数共同决定基因交流的节奏。迁移太频繁种群很快同质化岛屿模型退化成一个大种群失去多样性优势迁移太稀疏各岛闭门造车又体现不出协同效果。圈内比较常见的做法是环形拓扑加每10代迁移2个最优个体我一般也从这个起点开始调。2.3 细粒度模型什么时候才值得碰细粒度模型是遗传算法并行化的第三种常见思路它把每个个体看成网格中的一个格点选择、交叉只发生在邻域内理论上每次进化都天然并行。但细粒度模型的通信开销极大每个个体的遗传操作都要和邻居交换信息对进程间通信的延迟和带宽非常敏感。在Python里用标准库实现细粒度并行通信代价会远超计算收益往往得不偿失。我的建议是除非你已经用numba把热路径编译掉或者准备引入mpi4py走真正的分布式内存方案否则现阶段不需要在Python里直接碰细粒度模型。对大多数人来说主从模型和岛屿模型已经覆盖了90%以上的加速需求先把这两个跑明白比追一个理论更优但工程上难落地的模型实在得多。下面这张表总结三条路线在常规场景下的取舍模型适用场景代码改动量主要风险主从模型评估函数很重种群规模适中最小只改评估环节通信开销掩盖计算收益岛屿模型多峰函数、容易早熟的问题中等需要设计迁移迁移策略不当导致多样性丢失细粒度模型超大规模并行机群大通信方案复杂Python生态中不实用2.4 三个模型的选型决策流程我自己的判断顺序是这样的先给当前串行GA做一次耗时画像统计单代里评估占多少、遗传操作占多少。如果评估占比超过50%直接上主从模型如果占比不高但问题容易早熟说明瓶颈不在计算量而在搜索多样性这时候岛屿模型更合适。如果两者兼具就先做岛屿模型岛内再用主从方式并行评估两个层次叠加这也是生产中比较常见的组合。还有一个容易被忽略的点并行化不是万能药。如果单种群规模只有几十个个体评估本身也很轻开多进程的固定开销反而让总时间变长。这种时候应该先回头优化串行GA本身比如向量化评估函数、减少不必要的数组拷贝、用numba加速热点函数。并行化解决的是吞吐问题取代不了算法层面的优化。3. 用multiprocessing把串行GA改成并行评估最小可跑代码3.1 先搭一个串行GA基线并行化和性能优化类似前提是先有一个正确的串行版本否则并行只会让错误更快地放大。这里我用一个经典多峰测试函数Rastrigin作为目标因为它在二维空间里就有大量局部最优点能清楚看出GA是否陷入早熟也方便后续对比收敛质量。先写最小可跑的串行版import numpy as np def rastrigin(x): # 多峰函数适合观察遗传算法的收敛与停滞 n len(x) return 10.0 * n np.sum(x * x - 10.0 * np.cos(2.0 * np.pi * x)) def init_pop(pop_size, dim, lb, ub, rng): # 在上下界之间均匀采样生成初始种群 return rng.uniform(lb, ub, (pop_size, dim)) def evaluate_pop(pop, rng): # 串行评估整个种群这里是后续并行化的切入点 return np.array([rastrigin(ind) for ind in pop]) def tournament_select(pop, fitness, k, rng): # 锦标赛选择随机抽k个个体取其中适应度最优的 idx rng.choice(len(pop), sizek, replaceFalse) return pop[idx[np.argmin(fitness[idx])]] def arithmetic_crossover(a, b, rng): # 算术交叉按随机权重合成两个父代 alpha rng.uniform(0.0, 1.0) return alpha * a (1.0 - alpha) * b def gaussian_mutate(x, lb, ub, sigma, rng): # 高斯变异加噪声后裁剪到边界内 y x rng.normal(0.0, sigma, len(x)) return np.clip(y, lb, ub) def run_ga(pop_size, dim, lb, ub, generations, seed42): rng np.random.default_rng(seed) pop init_pop(pop_size, dim, lb, ub, rng) for gen in range(generations): fitness evaluate_pop(pop, rng) new_pop [] # 精英保留把上一代最优个体直接复制进下一代 elite_idx np.argmin(fitness) new_pop.append(pop[elite_idx].copy()) # 选择、交叉、变异直到填满新种群 while len(new_pop) pop_size: a tournament_select(pop, fitness, k3, rngrng) b tournament_select(pop, fitness, k3, rngrng) child arithmetic_crossover(a, b, rng) child gaussian_mutate(child, lb, ub, sigma0.2, rngrng) new_pop.append(child) pop np.array(new_pop) return pop, fitness这段代码的关键点有两个一个是evaluate_pop里的列表推导它逐个体计算目标函数就是我们要并行化的位置另一个是精英保留策略在并行化之后这个逻辑保证每一代的最优解不会被随机性覆盖掉。注意这里没有先算child的适应度再比较是一代替换式的进化逻辑简单且适合做并行基准。如果你还没跑过GA建议先用这个串行版本在二维Rastrigin上试一下。种群规模80跑50代大约每代要算80次函数。Rastrigin在这个设置下的单次评估在微秒级整体耗时很短但它已经能准确反映一个规律个体数量乘以代数就是串行版本的耗时模型。一旦换成真实工程里的重评估函数这个乘出来的数字就会变得很难看。3.2 改成Pool并行评估改动只在一个函数现在把evaluate_pop里的串行循环替换成multiprocessing的进程池。用Pool.map的好处是它会保持输入顺序返回的适应度列表和种群的索引一一对应不会因为并发导致后续选择逻辑错乱from multiprocessing import Pool import numpy as np def evaluate_one(x): # 每个子进程执行的评估函数 return rastrigin(x) class ParallelGASolver: def __init__(self, n_workersNone, chunksize8): # 进程池在初始化时创建一次整个进化过程复用 self.pool Pool(processesn_workers) self.chunksize chunksize def evaluate_pop(self, pop): # pool.map 按输入顺序返回结果索引对应关系不会乱 fitness self.pool.map(evaluate_one, [ind.copy() for ind in pop], chunksizeself.chunksize) return np.array(fitness) def close(self): self.pool.close() self.pool.join()使用方式很简单把原来调用run_ga里evaluate_pop的地方换成solver.evaluate_pop(pop)其他遗传操作一律不动。这个方案的改动量就是第3.1节串行代码里的一行循环因此主从模型是并行化入门最合适的切入点。这里两个参数需要解释一下。n_workers设为None时Pool会使用os.cpu_count()作为默认值但生产环境我建议显式传os.cpu_count() - 1留一个核给主进程做选择和调度避免机器上其他任务一起挤占CPU。chunksize决定一次性通过进程间通信发送多少个个体这个参数对性能影响很大后面单独说。还有一个细节需要注意传给pool.map的个体数组做了.copy()。虽然Linux下fork出的子进程会触发写时复制不显式拷贝一般也能跑但Windows下multiprocessing使用spawn方式启动子进程传入的对象会被序列化共享引用语义在不同平台上不一样。显式拷贝能让代码在Windows上表现一致避免一些难以排查的隐性共享问题。3.3 代码里的边界注意Pool对象要放进类的生命周期并行化落地时最容易犯的错误是把Pool创建放进每一代循环内部。每跑一代就创建一次进程池光是进程启动的开销就能抵消并行带来的收益。我自己早期就干过这事测出来比串行还慢还以为是并行方案的问题后来才发现进程启动成本被忽略了。正确的做法是像上面的代码一样把Pool作为求解器对象的一个属性在初始化时创建一次整个进化过程复用最后统一关闭。另一个相关经验是Pool对象不要直接放在模块全局变量里尤其是你在写可复用的库时。全局进程池会让使用者难以控制生命周期调试单测时也容易残留僵尸进程。把池封装在ParallelGASolver类里让外部通过上下文管理或close()显式关闭是更稳妥的设计。你可以在类里加一个__enter__和__exit__把资源管理做得更顺手但没有框架要求的话手动close已经够用。需要注意的是evaluate_one必须是一个模块顶层函数不能是局部函数或类方法。这是multiprocessing的序列化约束子进程要通过pickle获取函数定义嵌套函数无法被可靠地序列化。如果你确实需要在评估时传入额外参数可以用functools.partial包装或者把可变参数放到进程池初始化的initializer里。3.4 参数清单进程数、chunksize怎么调主从模型要调的参数不多但每个都很关键。我整理了经验值方便你起步时直接参考参数推荐值调整方向n_workers逻辑核数减1评估越重越接近核数评估轻则适当减少chunksize评估耗时小于1ms取16到321到10ms取4到8大于10ms取1到2越小负载越均衡越大吞吐越高种群规模维持串行版本规模并行不开源改变种群规模除非你发现每代task数量太少chunksize的调整逻辑是这样的进程间通信要做序列化和数据传输如果每个个体评估只需0.1毫秒而一次IPC要花0.5毫秒那通信开销就是计算开销的5倍。把几十个个体打包成一个chunk发送摊薄单次通信的开销。反过来如果每个个体要算几十毫秒chunksize太大反而容易让最后一个chunk的计算时间拖长整个世代这时候降到1或2让空闲进程尽快领走下一个任务负载更均衡。还有一种情况种群规模较大时可以考虑改用pool.imap代替pool.map。两者都能保持顺序但imap是惰性返回迭代器每收齐一个结果就可以立刻推进后续处理不用等整批算完。如果想做“每收齐一定比例结果就提前终止”的自适应策略imap更灵活。代码改动也很小把self.pool.map(..., chunksizeself.chunksize)换成self.pool.imap(..., chunksizeself.chunksize)即可。4. 岛屿模型落地迁移周期、迁移拓扑与Queue实现细节4.1 为什么岛屿模型适合Python岛屿模型天然契合多进程架构每个岛是一个独立的进程互不共享内存进程之间只需要定期传递少量个体。和主从模型相比它不需要一个中心调度者反复分发任务而是让多个GA实例各自埋头进化只在固定时刻交换信息。这种松散耦合的模型正好避开了Python多线程的GIL限制也避开了每个进程都要碰共享状态的复杂性。从工程角度看岛屿模型的容错性也更好。某一个岛因为数值问题卡住其他岛照常运行迁移时跳过这个没来消息的岛即可。相比之下主从模型里一个worker卡死整个世代的评估就要等它超时。这不是理论问题我实际调参时就遇到过某个岛因为变异越界导致评估函数抛出异常但另外三个岛依然收敛到了全局最优点附近的情况。4.2 迁移周期、迁移率和拓扑的选择迁移参数是岛屿模型的核心三个参数各管一件事。迁移周期决定基因交流的频率用代数计。周期太短外来基因频繁冲击本地种群本地好不容易形成的优良基因组合会被冲散周期太长各岛长期独立进化共享优秀基因的速度太慢。我在多峰函数上的经验是10代起步如果发现收敛曲线振荡厉害就往20代调如果发现某个岛长期停滞就往5代调。迁移率指每次迁出的个体数量。它的作用是引入新鲜基因而不是接管整个岛的进化方向。迁移率过大比如一次迁出10个个体接收方的种群会被外来个体占据较大比例几个岛很快同质化。我一般控制在种群规模的5%以内常见配置是每岛50个个体每次迁移1到3个最优个体。注意迁出的应是适应度最优的个体它们携带的基因更有价值。迁移拓扑最常见的是环形和全连接。环形拓扑实现简单每个岛只和邻居交流基因扩散需要多跳保留了一定的局部差异性。全连接拓扑每个岛都能收到所有其他岛的精英基因扩散快但更容易导致整个系统快速收敛到同一个解。如果目标是多样性优先选环形如果目标是把所有岛的最优基因尽快汇合选全连接。另外还有随机拓扑和动态拓扑工程上可以先从环形起步因为它最不容易翻车。下面这张表给出三个参数的起点和调整方向参数起点现象与调整迁移周期10代收敛曲线剧烈振荡上调停滞下调迁移率2个个体各岛最优值很快一致时降到1多样性过强且无收敛趋势时加量拓扑环形搜索效率不够时换全连接但注意监控种群多样性4.3 用Process与Queue实现最小环形岛屿框架下面给出一个简化但完整的环形岛屿模型骨架。每个岛是一个独立进程运行一个串行GA循环每过migrate_interval代岛把自己的最优个体发到下一个邻居的收件队列同时尝试从自己的收件队列里取邻居发来的个体替换掉本岛最差个体from multiprocessing import Process, Queue import numpy as np def island_worker(worker_id, generations, send_q, recv_q, params, seed): # 每个岛使用独立的随机数流避免所有岛步调一致 rng np.random.default_rng(seed) lb, ub params[lb], params[ub] pop init_pop(params[pop_size], params[dim], lb, ub, rng) for gen in range(generations): fitness np.array([rastrigin(ind) for ind in pop]) new_pop [] elite_idx int(np.argmin(fitness)) new_pop.append(pop[elite_idx].copy()) while len(new_pop) params[pop_size]: a tournament_select(pop, fitness, k3, rngrng) b tournament_select(pop, fitness, k3, rngrng) child arithmetic_crossover(a, b, rng) child gaussian_mutate(child, lb, ub, params[sigma], rng) new_pop.append(child) pop np.array(new_pop) fitness np.array([rastrigin(ind) for ind in pop]) # 到达迁移周期时把本岛最优个体发给邻居 if gen % params[migrate_interval] 0: send_q.put((worker_id, pop[elite_idx].copy())) # 尝试从接收队列取邻居发来的个体替换本岛最差 if not recv_q.empty(): _, migrant recv_q.get() worst_idx int(np.argmax(fitness)) pop[worst_idx] migrant return主进程负责按环形拓扑接好各岛的收发队列然后启动全部进程def run_islands(n_islands, generations, params, seeds): # 每个岛一个接收队列 recv_qs [Queue() for _ in range(n_islands)] procs [] for i in range(n_islands): # 环形拓扑本岛的发送队列指向下一个岛的接收队列 send_q recv_qs[(i 1) % n_islands] p Process(targetisland_worker, args(i, generations, send_q, recv_qs[i], params, seeds[i])) procs.append(p) p.start() for p in procs: p.join()注意这里发送队列和接收队列的接法岛i调用send_q.put数据进入的是岛(i1)的recv_q岛i自己的recv_q接收的是岛(i-1)发来的数据。这样每个岛只与左右邻居交流环形拓扑就成立了。put默认是阻塞调用如果队列满会等待不过迁移周期是10代每代只发一个个体队列基本不会满。发送时做了.copy()防止后续变异通过引用修改已经放入队列的数组。种子设置是个容易忽视的细节。每个岛必须用不同的随机数种子否则所有岛的进化轨迹完全相同迁移就变成自己发给自己岛屿模型退化成单一种群。上面的代码里seeds由外部传入我一般用[base_seed i * 101 for i in range(n_islands)]这类互不重叠的序列生成而不是像串行版本那样直接固定用同一个seed。这个骨架还有一处和真实工程场景不同的简化岛内评估用的是串行循环。如果你要做“岛屿内并行评估”最直接的办法是在island_worker内部创建multiprocessing.Pool做评估但要注意不要每代创建。更好的方式是仿照第三章的ParallelGASolver在岛屿进程里维护一个常驻池。两个尺度叠加就是岛屿模型加主从模型的多层并行。代价是进程数量较多时机器可能需要几十个核才跑得动量力而行。4.4 主进程如何收场join与队列清理岛屿模型的进程管理比主从模型更需要注意收场。每个岛进程有明确的代数上限跑完即返回主进程的join()会正常结束。但如果你的实现在循环里有while True或者某个异常让进程提前退出join()依然能返回可队列里可能残留大量未读的数据。Python的multiprocessing.Queue在进程退出时会把缓冲数据刷新到管道如果队列没有被完整读取有些平台上会留下一个后台线程让进程无法干净退出甚至触发AssertionError。我的习惯是所有岛进程结束后显式检查每个队列并把残留消息取干净然后再调用q.close()和q.join_thread()。大多数短跑实验里队列不会积压但这个收场习惯能避免在长实验里遇到灵异卡死。5. 并行GA常见问题排查四个让人翻车的坑5.1 并行跑起来比串行还慢加速比小于1现象同样的问题同样代数加了multiprocessing之后运行时间反而增加了任务管理器里能看到多核都在忙但总时长就是下不来。原因这个坑我踩过两次根源基本都出在chunksize和评估耗时的不匹配上。当单次适应度评估只有微秒级时进程间通信和序列化的开销远远大于计算本身。每代都要把上百个个体打包发送、解码、再回收结果这些附加成本最后都算在总时间里。解决先给evaluate_one加一行计时日志连续跑50次算出单次评估平均耗时。如果小于1毫秒直接把chunksize调大到16以上把通信次数降下来。如果调整后仍然没有加速说明问题根本不值得并行化回到串行版本考虑用numba或向量化重写评估函数更实际。5.2 每次实验结果完全一样多样性去哪了现象并行GA运行多次每次给出的最优解、收敛曲线几乎一模一样岛屿模型跑了几十代各岛最优值从第一代开始就保持相近。原因最典型的场景是随机数使用不当。有人用random.seed(42)写在模块顶部子进程被fork时继承了同一个随机数生成器状态所有worker产生的随机数序列完全一致。另一种情况是numpy新版本推荐用default_rng但你在每个worker里用同一个seed创建了独立的生成器结果同样同步。解决给每个子进程分配互不相同的种子。主从模型里可以通过chunksize无法传递种子那就在初始化的initializer函数里按worker编号设置种子岛屿模型则按岛编号生成种子就像第四章代码里演示的那样。调试时可以用固定种子复现但上线跑真实任务时一定要把种子分离开。5.3 子进程抛异常主进程无声卡死现象并行GA跑着跑着就没有输出了CPU占用全部降为零进程既不报错也不退出只好强制杀掉重跑。原因pool.map在子进程抛出未捕获异常时主进程并不能立刻感知。如果某个worker在评估函数里触发了数值错误它会把异常信息回传给主进程但主进程此时仍在等待其他worker返回结果如果其他worker没有正常结束整个程序看起来就是卡死状态。解决给worker函数包一层异常捕获把异常信息通过队列或返回值传到主进程。一个简单可靠的做法是让evaluate_one返回一个带标志位的元组例如(value, error_msg)主进程拿回结果后检查标志位并终止迭代。另外把Pool的maxtasksperchild设为100让每个worker在处理一定数量任务后自动重启可以避免子进程内部状态长期累积导致的隐性异常。5.4 岛屿模型跑着跑着所有岛的最优解变得一模一样现象一开始各岛收敛曲线有差异但几十代之后四个岛的最优值曲线完全重合后续的进化再也看不到分叉。原因迁移策略过于激进。迁移周期只有两三代迁移率又设成5个甚至10个个体外来优秀基因还没在本地繁殖就被搬进搬出各岛种群的基因池迅速同质化。这时候岛屿模型退化成一个大种群多样性优势没了早熟风险反而比串行GA更高。解决拉长迁移周期降到每10到20代迁移一次每次只迁1到2个个体替换目标选本地最差个体而不是随机个体。改动后重新观察各岛最优值曲线的分离程度理想状态下各岛前期应有明显差异中后期逐步靠拢而不是第一代迁移后就完全重叠。5.5 并行评估后精英个体丢失收敛质量下降现象加入并行化之后结果质量反而比串行GA差最优个体在若干代后消失收敛曲线出现回弹。原因并行化改变了评估结果的返回顺序或时间间隔。如果你用的是pool.imap_unordered返回顺序不保证和输入一致而后续的选择逻辑却假设第i个结果是第i个个体的适应度。一旦错位精英保留找到的不再是真正的最优个体下一代自然丢失了宝贵基因。解决要么用保持顺序的pool.map要么在imap_unordered场景下把结果按个体索引重新排列。我的习惯是能保持顺序就尽量保持只在需要提前终止优化时才用imap并自行做索引对齐。修改完记得用固定种子的串行版本做一次对照确认并行版本的质量没有系统性退化。6. 用控制变量的对比实验验证并行加速比一套可靠的测法6.1 最小对比矩阵既然要做并行方案就要用数据说话。我的验证流程是先固定所有可控因素再比较三个版本串行GA、主从并行GA、岛屿模型GA。三个版本使用同一个Rastrigin函数、同一个初代种子、同样的总评估量。总评估量是关键主从模型和串行版的种群代数完全一致岛屿模型因为分成多个岛单个岛的种群规模可以小一些但要保证所有岛的总个体数乘以代数与串行版本一致否则对比就不公平。每组实验跑三遍取中位数记录两个指标总墙钟时间和最终最优适应度。下面是我常用的记录表版本总代数单代评估次数总评估次数耗时中位数最优适应度中位数串行GA50804000记录记录主从并行GA50804000记录记录岛屿4岛504x204000记录记录6.2 看收敛曲线更要看每代耗时光比最终时间还不够我还会把每代的累计耗时打点画出来观察并行版本的每代耗时是否稳定。有些并行实现在前几代速度快但后续因为队列积压或进程调度波动每代耗时逐渐变长。用matplotlib把串行和并行的每代耗时曲线叠在一起如果并行曲线在后半段明显上翘说明存在负载不均衡需要回头调chunksize或岛屿迁移周期。最后说一个我从翻车里换来的习惯动手并行之前永远先跑一次串行的耗时画像。评估占比不到一半就先别开池占比很大才值得上主从或岛屿。并行GA不是玄学但它确实对使用条件敏感——选对了多快好省选错了不仅没快还会引入一整套进程管理问题。希望这套验证方法和踩坑记录能帮你少折腾几个晚上。希望帮到你。本文还有配套的精品资源点击获取
Python并行遗传算法实战：主从与岛屿模型提速指南
简介面向算法学习者与开发者的基于 Python 的并行遗传算法实现针对大规模优化问题计算耗时的痛点演示利用多进程或线程池将种群分割、并行执行选择与交叉变异的关键思路。包内共两个脚本文件涵盖主程序与算法核心模块整体仅约六千字节轻量易读适合快速上手。压缩包中包含两个脚本可对照理解串行遗传算法步骤与并行化改造方式。已有二百二十四人学习下载说明具备一定参考价值。示例代码可直接运行两个脚本均包含清晰注释便于理解关键逻辑。读者可获得可运行的并行遗传算法示例代码、种群初始化、适应度评价、选择、交叉、变异的标准流程以及负载均衡、数据同步等并行优化注意事项的代码化演示适合入门并行计算或遗传算法实践的开发者。1. 并行遗传算法GAPython里把优化提速的实用路径跑过遗传算法的人大概率经历过这种事函数写对了种群规模调到100代数放到200结果一跑就是一夜。稍微复杂一点的规划、调度或模型参数标定问题单次适应度评估就要几十毫秒串行版本整个进化过程慢到让人怀疑人生。并行遗传算法GA要解决的就是这个时间瓶颈——把个体评估拆到多进程里或者让多个种群各跑各的进化再定期交换个体。它不是换一个算法而是给遗传算法接上多核算力的管道。这篇文章写给两类人一类是写过串行GA、被性能卡住、想找个可靠并行方案的另一类是刚接触遗传算法希望一步到位、直接写并行版本的程序员。我会从并行模型的选择讲起用可复现的Python代码把主从模型和岛屿模型跑通再把几个让我翻过车的坑逐一拆开最后给出一套能说服自己也能说服团队的加速比验证方法。2. 并行GA的三条技术路线主从、岛屿、细粒度怎么选2.1 主从模型适应度评估是瓶颈时就选它主从模型是并行化遗传算法里改动最小、收益最直接的一种。主进程负责执行选择、交叉、变异这些遗传操作把这一代种群打包发给多个工作进程去计算适应度收齐结果后再继续下一代。整个算法的逻辑和串行版本几乎一致唯一变化就是把“循环计算每个个体的适应度”变成了“派发任务并回收结果”。选择主从模型的条件非常明确当适应度评估耗时占单代总耗时的一半以上时这个模型几乎是最优解。比如你用一个数值仿真器评估个体或者跑一个复杂的惩罚函数单次评估要几十毫秒到几秒那么评估环节就是明显的热点。并行化这一块收益能直接反映在墙钟时间上。需要特别说明的是Python里做这类CPU密集型并行不要用threading。Python的GIL锁决定了同一进程内多个线程无法真正并行执行Python字节码纯计算任务用线程反而会比串行更慢。我见过不少人拿着threading改三行就去测速结果发现并行GA比串行还慢这不是方案错是并发工具选错了。主从模型在Python里的正确落地方式是multiprocessing后面第三章会给出完整代码。2.2 岛屿模型解决早熟收敛顺带真正并行岛屿模型和主从模型的思路完全不同。它不把单个种群拆开而是同时维护多个相对独立的子种群每个子种群像一座岛一样独立进化每隔若干代把各自的精英个体迁移给相邻的岛。这样做有两个好处一是多个种群天然并行二是迁移机制能显著缓解遗传算法最常见的早熟收敛问题。遗传算法在单一种群里一旦某个较优个体通过选择迅速扩散整个种群的多样性就会下降后续很难跳脱局部最优。而岛屿模型里每个岛的进化方向可能各不相同一个岛陷入局部最优时其他岛可能还在更广阔的区域搜索。通过迁移那些携带不同基因的个体会被引入相当于给陷入停滞的岛注入了新的进化动力。岛屿模型需要关注三个参数迁移周期每隔多少代迁移一次、迁移率每次迁出多少个个体和迁移拓扑岛与岛之间的连接关系。这三个参数共同决定基因交流的节奏。迁移太频繁种群很快同质化岛屿模型退化成一个大种群失去多样性优势迁移太稀疏各岛闭门造车又体现不出协同效果。圈内比较常见的做法是环形拓扑加每10代迁移2个最优个体我一般也从这个起点开始调。2.3 细粒度模型什么时候才值得碰细粒度模型是遗传算法并行化的第三种常见思路它把每个个体看成网格中的一个格点选择、交叉只发生在邻域内理论上每次进化都天然并行。但细粒度模型的通信开销极大每个个体的遗传操作都要和邻居交换信息对进程间通信的延迟和带宽非常敏感。在Python里用标准库实现细粒度并行通信代价会远超计算收益往往得不偿失。我的建议是除非你已经用numba把热路径编译掉或者准备引入mpi4py走真正的分布式内存方案否则现阶段不需要在Python里直接碰细粒度模型。对大多数人来说主从模型和岛屿模型已经覆盖了90%以上的加速需求先把这两个跑明白比追一个理论更优但工程上难落地的模型实在得多。下面这张表总结三条路线在常规场景下的取舍模型适用场景代码改动量主要风险主从模型评估函数很重种群规模适中最小只改评估环节通信开销掩盖计算收益岛屿模型多峰函数、容易早熟的问题中等需要设计迁移迁移策略不当导致多样性丢失细粒度模型超大规模并行机群大通信方案复杂Python生态中不实用2.4 三个模型的选型决策流程我自己的判断顺序是这样的先给当前串行GA做一次耗时画像统计单代里评估占多少、遗传操作占多少。如果评估占比超过50%直接上主从模型如果占比不高但问题容易早熟说明瓶颈不在计算量而在搜索多样性这时候岛屿模型更合适。如果两者兼具就先做岛屿模型岛内再用主从方式并行评估两个层次叠加这也是生产中比较常见的组合。还有一个容易被忽略的点并行化不是万能药。如果单种群规模只有几十个个体评估本身也很轻开多进程的固定开销反而让总时间变长。这种时候应该先回头优化串行GA本身比如向量化评估函数、减少不必要的数组拷贝、用numba加速热点函数。并行化解决的是吞吐问题取代不了算法层面的优化。3. 用multiprocessing把串行GA改成并行评估最小可跑代码3.1 先搭一个串行GA基线并行化和性能优化类似前提是先有一个正确的串行版本否则并行只会让错误更快地放大。这里我用一个经典多峰测试函数Rastrigin作为目标因为它在二维空间里就有大量局部最优点能清楚看出GA是否陷入早熟也方便后续对比收敛质量。先写最小可跑的串行版import numpy as np def rastrigin(x): # 多峰函数适合观察遗传算法的收敛与停滞 n len(x) return 10.0 * n np.sum(x * x - 10.0 * np.cos(2.0 * np.pi * x)) def init_pop(pop_size, dim, lb, ub, rng): # 在上下界之间均匀采样生成初始种群 return rng.uniform(lb, ub, (pop_size, dim)) def evaluate_pop(pop, rng): # 串行评估整个种群这里是后续并行化的切入点 return np.array([rastrigin(ind) for ind in pop]) def tournament_select(pop, fitness, k, rng): # 锦标赛选择随机抽k个个体取其中适应度最优的 idx rng.choice(len(pop), sizek, replaceFalse) return pop[idx[np.argmin(fitness[idx])]] def arithmetic_crossover(a, b, rng): # 算术交叉按随机权重合成两个父代 alpha rng.uniform(0.0, 1.0) return alpha * a (1.0 - alpha) * b def gaussian_mutate(x, lb, ub, sigma, rng): # 高斯变异加噪声后裁剪到边界内 y x rng.normal(0.0, sigma, len(x)) return np.clip(y, lb, ub) def run_ga(pop_size, dim, lb, ub, generations, seed42): rng np.random.default_rng(seed) pop init_pop(pop_size, dim, lb, ub, rng) for gen in range(generations): fitness evaluate_pop(pop, rng) new_pop [] # 精英保留把上一代最优个体直接复制进下一代 elite_idx np.argmin(fitness) new_pop.append(pop[elite_idx].copy()) # 选择、交叉、变异直到填满新种群 while len(new_pop) pop_size: a tournament_select(pop, fitness, k3, rngrng) b tournament_select(pop, fitness, k3, rngrng) child arithmetic_crossover(a, b, rng) child gaussian_mutate(child, lb, ub, sigma0.2, rngrng) new_pop.append(child) pop np.array(new_pop) return pop, fitness这段代码的关键点有两个一个是evaluate_pop里的列表推导它逐个体计算目标函数就是我们要并行化的位置另一个是精英保留策略在并行化之后这个逻辑保证每一代的最优解不会被随机性覆盖掉。注意这里没有先算child的适应度再比较是一代替换式的进化逻辑简单且适合做并行基准。如果你还没跑过GA建议先用这个串行版本在二维Rastrigin上试一下。种群规模80跑50代大约每代要算80次函数。Rastrigin在这个设置下的单次评估在微秒级整体耗时很短但它已经能准确反映一个规律个体数量乘以代数就是串行版本的耗时模型。一旦换成真实工程里的重评估函数这个乘出来的数字就会变得很难看。3.2 改成Pool并行评估改动只在一个函数现在把evaluate_pop里的串行循环替换成multiprocessing的进程池。用Pool.map的好处是它会保持输入顺序返回的适应度列表和种群的索引一一对应不会因为并发导致后续选择逻辑错乱from multiprocessing import Pool import numpy as np def evaluate_one(x): # 每个子进程执行的评估函数 return rastrigin(x) class ParallelGASolver: def __init__(self, n_workersNone, chunksize8): # 进程池在初始化时创建一次整个进化过程复用 self.pool Pool(processesn_workers) self.chunksize chunksize def evaluate_pop(self, pop): # pool.map 按输入顺序返回结果索引对应关系不会乱 fitness self.pool.map(evaluate_one, [ind.copy() for ind in pop], chunksizeself.chunksize) return np.array(fitness) def close(self): self.pool.close() self.pool.join()使用方式很简单把原来调用run_ga里evaluate_pop的地方换成solver.evaluate_pop(pop)其他遗传操作一律不动。这个方案的改动量就是第3.1节串行代码里的一行循环因此主从模型是并行化入门最合适的切入点。这里两个参数需要解释一下。n_workers设为None时Pool会使用os.cpu_count()作为默认值但生产环境我建议显式传os.cpu_count() - 1留一个核给主进程做选择和调度避免机器上其他任务一起挤占CPU。chunksize决定一次性通过进程间通信发送多少个个体这个参数对性能影响很大后面单独说。还有一个细节需要注意传给pool.map的个体数组做了.copy()。虽然Linux下fork出的子进程会触发写时复制不显式拷贝一般也能跑但Windows下multiprocessing使用spawn方式启动子进程传入的对象会被序列化共享引用语义在不同平台上不一样。显式拷贝能让代码在Windows上表现一致避免一些难以排查的隐性共享问题。3.3 代码里的边界注意Pool对象要放进类的生命周期并行化落地时最容易犯的错误是把Pool创建放进每一代循环内部。每跑一代就创建一次进程池光是进程启动的开销就能抵消并行带来的收益。我自己早期就干过这事测出来比串行还慢还以为是并行方案的问题后来才发现进程启动成本被忽略了。正确的做法是像上面的代码一样把Pool作为求解器对象的一个属性在初始化时创建一次整个进化过程复用最后统一关闭。另一个相关经验是Pool对象不要直接放在模块全局变量里尤其是你在写可复用的库时。全局进程池会让使用者难以控制生命周期调试单测时也容易残留僵尸进程。把池封装在ParallelGASolver类里让外部通过上下文管理或close()显式关闭是更稳妥的设计。你可以在类里加一个__enter__和__exit__把资源管理做得更顺手但没有框架要求的话手动close已经够用。需要注意的是evaluate_one必须是一个模块顶层函数不能是局部函数或类方法。这是multiprocessing的序列化约束子进程要通过pickle获取函数定义嵌套函数无法被可靠地序列化。如果你确实需要在评估时传入额外参数可以用functools.partial包装或者把可变参数放到进程池初始化的initializer里。3.4 参数清单进程数、chunksize怎么调主从模型要调的参数不多但每个都很关键。我整理了经验值方便你起步时直接参考参数推荐值调整方向n_workers逻辑核数减1评估越重越接近核数评估轻则适当减少chunksize评估耗时小于1ms取16到321到10ms取4到8大于10ms取1到2越小负载越均衡越大吞吐越高种群规模维持串行版本规模并行不开源改变种群规模除非你发现每代task数量太少chunksize的调整逻辑是这样的进程间通信要做序列化和数据传输如果每个个体评估只需0.1毫秒而一次IPC要花0.5毫秒那通信开销就是计算开销的5倍。把几十个个体打包成一个chunk发送摊薄单次通信的开销。反过来如果每个个体要算几十毫秒chunksize太大反而容易让最后一个chunk的计算时间拖长整个世代这时候降到1或2让空闲进程尽快领走下一个任务负载更均衡。还有一种情况种群规模较大时可以考虑改用pool.imap代替pool.map。两者都能保持顺序但imap是惰性返回迭代器每收齐一个结果就可以立刻推进后续处理不用等整批算完。如果想做“每收齐一定比例结果就提前终止”的自适应策略imap更灵活。代码改动也很小把self.pool.map(..., chunksizeself.chunksize)换成self.pool.imap(..., chunksizeself.chunksize)即可。4. 岛屿模型落地迁移周期、迁移拓扑与Queue实现细节4.1 为什么岛屿模型适合Python岛屿模型天然契合多进程架构每个岛是一个独立的进程互不共享内存进程之间只需要定期传递少量个体。和主从模型相比它不需要一个中心调度者反复分发任务而是让多个GA实例各自埋头进化只在固定时刻交换信息。这种松散耦合的模型正好避开了Python多线程的GIL限制也避开了每个进程都要碰共享状态的复杂性。从工程角度看岛屿模型的容错性也更好。某一个岛因为数值问题卡住其他岛照常运行迁移时跳过这个没来消息的岛即可。相比之下主从模型里一个worker卡死整个世代的评估就要等它超时。这不是理论问题我实际调参时就遇到过某个岛因为变异越界导致评估函数抛出异常但另外三个岛依然收敛到了全局最优点附近的情况。4.2 迁移周期、迁移率和拓扑的选择迁移参数是岛屿模型的核心三个参数各管一件事。迁移周期决定基因交流的频率用代数计。周期太短外来基因频繁冲击本地种群本地好不容易形成的优良基因组合会被冲散周期太长各岛长期独立进化共享优秀基因的速度太慢。我在多峰函数上的经验是10代起步如果发现收敛曲线振荡厉害就往20代调如果发现某个岛长期停滞就往5代调。迁移率指每次迁出的个体数量。它的作用是引入新鲜基因而不是接管整个岛的进化方向。迁移率过大比如一次迁出10个个体接收方的种群会被外来个体占据较大比例几个岛很快同质化。我一般控制在种群规模的5%以内常见配置是每岛50个个体每次迁移1到3个最优个体。注意迁出的应是适应度最优的个体它们携带的基因更有价值。迁移拓扑最常见的是环形和全连接。环形拓扑实现简单每个岛只和邻居交流基因扩散需要多跳保留了一定的局部差异性。全连接拓扑每个岛都能收到所有其他岛的精英基因扩散快但更容易导致整个系统快速收敛到同一个解。如果目标是多样性优先选环形如果目标是把所有岛的最优基因尽快汇合选全连接。另外还有随机拓扑和动态拓扑工程上可以先从环形起步因为它最不容易翻车。下面这张表给出三个参数的起点和调整方向参数起点现象与调整迁移周期10代收敛曲线剧烈振荡上调停滞下调迁移率2个个体各岛最优值很快一致时降到1多样性过强且无收敛趋势时加量拓扑环形搜索效率不够时换全连接但注意监控种群多样性4.3 用Process与Queue实现最小环形岛屿框架下面给出一个简化但完整的环形岛屿模型骨架。每个岛是一个独立进程运行一个串行GA循环每过migrate_interval代岛把自己的最优个体发到下一个邻居的收件队列同时尝试从自己的收件队列里取邻居发来的个体替换掉本岛最差个体from multiprocessing import Process, Queue import numpy as np def island_worker(worker_id, generations, send_q, recv_q, params, seed): # 每个岛使用独立的随机数流避免所有岛步调一致 rng np.random.default_rng(seed) lb, ub params[lb], params[ub] pop init_pop(params[pop_size], params[dim], lb, ub, rng) for gen in range(generations): fitness np.array([rastrigin(ind) for ind in pop]) new_pop [] elite_idx int(np.argmin(fitness)) new_pop.append(pop[elite_idx].copy()) while len(new_pop) params[pop_size]: a tournament_select(pop, fitness, k3, rngrng) b tournament_select(pop, fitness, k3, rngrng) child arithmetic_crossover(a, b, rng) child gaussian_mutate(child, lb, ub, params[sigma], rng) new_pop.append(child) pop np.array(new_pop) fitness np.array([rastrigin(ind) for ind in pop]) # 到达迁移周期时把本岛最优个体发给邻居 if gen % params[migrate_interval] 0: send_q.put((worker_id, pop[elite_idx].copy())) # 尝试从接收队列取邻居发来的个体替换本岛最差 if not recv_q.empty(): _, migrant recv_q.get() worst_idx int(np.argmax(fitness)) pop[worst_idx] migrant return主进程负责按环形拓扑接好各岛的收发队列然后启动全部进程def run_islands(n_islands, generations, params, seeds): # 每个岛一个接收队列 recv_qs [Queue() for _ in range(n_islands)] procs [] for i in range(n_islands): # 环形拓扑本岛的发送队列指向下一个岛的接收队列 send_q recv_qs[(i 1) % n_islands] p Process(targetisland_worker, args(i, generations, send_q, recv_qs[i], params, seeds[i])) procs.append(p) p.start() for p in procs: p.join()注意这里发送队列和接收队列的接法岛i调用send_q.put数据进入的是岛(i1)的recv_q岛i自己的recv_q接收的是岛(i-1)发来的数据。这样每个岛只与左右邻居交流环形拓扑就成立了。put默认是阻塞调用如果队列满会等待不过迁移周期是10代每代只发一个个体队列基本不会满。发送时做了.copy()防止后续变异通过引用修改已经放入队列的数组。种子设置是个容易忽视的细节。每个岛必须用不同的随机数种子否则所有岛的进化轨迹完全相同迁移就变成自己发给自己岛屿模型退化成单一种群。上面的代码里seeds由外部传入我一般用[base_seed i * 101 for i in range(n_islands)]这类互不重叠的序列生成而不是像串行版本那样直接固定用同一个seed。这个骨架还有一处和真实工程场景不同的简化岛内评估用的是串行循环。如果你要做“岛屿内并行评估”最直接的办法是在island_worker内部创建multiprocessing.Pool做评估但要注意不要每代创建。更好的方式是仿照第三章的ParallelGASolver在岛屿进程里维护一个常驻池。两个尺度叠加就是岛屿模型加主从模型的多层并行。代价是进程数量较多时机器可能需要几十个核才跑得动量力而行。4.4 主进程如何收场join与队列清理岛屿模型的进程管理比主从模型更需要注意收场。每个岛进程有明确的代数上限跑完即返回主进程的join()会正常结束。但如果你的实现在循环里有while True或者某个异常让进程提前退出join()依然能返回可队列里可能残留大量未读的数据。Python的multiprocessing.Queue在进程退出时会把缓冲数据刷新到管道如果队列没有被完整读取有些平台上会留下一个后台线程让进程无法干净退出甚至触发AssertionError。我的习惯是所有岛进程结束后显式检查每个队列并把残留消息取干净然后再调用q.close()和q.join_thread()。大多数短跑实验里队列不会积压但这个收场习惯能避免在长实验里遇到灵异卡死。5. 并行GA常见问题排查四个让人翻车的坑5.1 并行跑起来比串行还慢加速比小于1现象同样的问题同样代数加了multiprocessing之后运行时间反而增加了任务管理器里能看到多核都在忙但总时长就是下不来。原因这个坑我踩过两次根源基本都出在chunksize和评估耗时的不匹配上。当单次适应度评估只有微秒级时进程间通信和序列化的开销远远大于计算本身。每代都要把上百个个体打包发送、解码、再回收结果这些附加成本最后都算在总时间里。解决先给evaluate_one加一行计时日志连续跑50次算出单次评估平均耗时。如果小于1毫秒直接把chunksize调大到16以上把通信次数降下来。如果调整后仍然没有加速说明问题根本不值得并行化回到串行版本考虑用numba或向量化重写评估函数更实际。5.2 每次实验结果完全一样多样性去哪了现象并行GA运行多次每次给出的最优解、收敛曲线几乎一模一样岛屿模型跑了几十代各岛最优值从第一代开始就保持相近。原因最典型的场景是随机数使用不当。有人用random.seed(42)写在模块顶部子进程被fork时继承了同一个随机数生成器状态所有worker产生的随机数序列完全一致。另一种情况是numpy新版本推荐用default_rng但你在每个worker里用同一个seed创建了独立的生成器结果同样同步。解决给每个子进程分配互不相同的种子。主从模型里可以通过chunksize无法传递种子那就在初始化的initializer函数里按worker编号设置种子岛屿模型则按岛编号生成种子就像第四章代码里演示的那样。调试时可以用固定种子复现但上线跑真实任务时一定要把种子分离开。5.3 子进程抛异常主进程无声卡死现象并行GA跑着跑着就没有输出了CPU占用全部降为零进程既不报错也不退出只好强制杀掉重跑。原因pool.map在子进程抛出未捕获异常时主进程并不能立刻感知。如果某个worker在评估函数里触发了数值错误它会把异常信息回传给主进程但主进程此时仍在等待其他worker返回结果如果其他worker没有正常结束整个程序看起来就是卡死状态。解决给worker函数包一层异常捕获把异常信息通过队列或返回值传到主进程。一个简单可靠的做法是让evaluate_one返回一个带标志位的元组例如(value, error_msg)主进程拿回结果后检查标志位并终止迭代。另外把Pool的maxtasksperchild设为100让每个worker在处理一定数量任务后自动重启可以避免子进程内部状态长期累积导致的隐性异常。5.4 岛屿模型跑着跑着所有岛的最优解变得一模一样现象一开始各岛收敛曲线有差异但几十代之后四个岛的最优值曲线完全重合后续的进化再也看不到分叉。原因迁移策略过于激进。迁移周期只有两三代迁移率又设成5个甚至10个个体外来优秀基因还没在本地繁殖就被搬进搬出各岛种群的基因池迅速同质化。这时候岛屿模型退化成一个大种群多样性优势没了早熟风险反而比串行GA更高。解决拉长迁移周期降到每10到20代迁移一次每次只迁1到2个个体替换目标选本地最差个体而不是随机个体。改动后重新观察各岛最优值曲线的分离程度理想状态下各岛前期应有明显差异中后期逐步靠拢而不是第一代迁移后就完全重叠。5.5 并行评估后精英个体丢失收敛质量下降现象加入并行化之后结果质量反而比串行GA差最优个体在若干代后消失收敛曲线出现回弹。原因并行化改变了评估结果的返回顺序或时间间隔。如果你用的是pool.imap_unordered返回顺序不保证和输入一致而后续的选择逻辑却假设第i个结果是第i个个体的适应度。一旦错位精英保留找到的不再是真正的最优个体下一代自然丢失了宝贵基因。解决要么用保持顺序的pool.map要么在imap_unordered场景下把结果按个体索引重新排列。我的习惯是能保持顺序就尽量保持只在需要提前终止优化时才用imap并自行做索引对齐。修改完记得用固定种子的串行版本做一次对照确认并行版本的质量没有系统性退化。6. 用控制变量的对比实验验证并行加速比一套可靠的测法6.1 最小对比矩阵既然要做并行方案就要用数据说话。我的验证流程是先固定所有可控因素再比较三个版本串行GA、主从并行GA、岛屿模型GA。三个版本使用同一个Rastrigin函数、同一个初代种子、同样的总评估量。总评估量是关键主从模型和串行版的种群代数完全一致岛屿模型因为分成多个岛单个岛的种群规模可以小一些但要保证所有岛的总个体数乘以代数与串行版本一致否则对比就不公平。每组实验跑三遍取中位数记录两个指标总墙钟时间和最终最优适应度。下面是我常用的记录表版本总代数单代评估次数总评估次数耗时中位数最优适应度中位数串行GA50804000记录记录主从并行GA50804000记录记录岛屿4岛504x204000记录记录6.2 看收敛曲线更要看每代耗时光比最终时间还不够我还会把每代的累计耗时打点画出来观察并行版本的每代耗时是否稳定。有些并行实现在前几代速度快但后续因为队列积压或进程调度波动每代耗时逐渐变长。用matplotlib把串行和并行的每代耗时曲线叠在一起如果并行曲线在后半段明显上翘说明存在负载不均衡需要回头调chunksize或岛屿迁移周期。最后说一个我从翻车里换来的习惯动手并行之前永远先跑一次串行的耗时画像。评估占比不到一半就先别开池占比很大才值得上主从或岛屿。并行GA不是玄学但它确实对使用条件敏感——选对了多快好省选错了不仅没快还会引入一整套进程管理问题。希望这套验证方法和踩坑记录能帮你少折腾几个晚上。希望帮到你。本文还有配套的精品资源点击获取
