Julia中PSO求解ODE的代码为何重复运行变慢？莫名提速原因

两类运行异常的底层机制 #

1. 重复轮次逐轮涨耗时的核心原因 #

• 堆内存碎片化累积：代码中particles = []为无类型动态数组，每轮PSO运行产生的粒子对象、ODE求解临时数组、求解器内部缓存残留在堆上，没有统一的内存复用机制。随着运行轮次增加，碎片化内存块数量线性上涨，垃圾回收器的扫描范围逐步扩大，直接推高单轮耗时，刚好匹配每轮多耗3~5秒的线性增长趋势。
• ODE对象重复创建的开销累积：cost_func中每次计算适应度都会新建ODEProblem对象，求解器需要每次重新初始化内部雅可比缓存、步长控制状态，这些对象没有复用通道，旧的临时缓存残留越多，新内存分配的命中率越低。
• 多线程共享写的隐性开销：@threads循环内直接修改全局gbest对象的属性，没有加线程同步锁，随着运行轮次增加，多核之间的缓存一致性同步开销会逐步上升，进一步推高耗时。

2. 后期莫名大幅提速的核心原因 #

• 这不是常规的首次JIT预热，是运行时编译完成了全路径静态优化：无类型的particles数组会触发前期的动态分派，前20轮运行刚好把所有可能的调用分支（不同参数下的ODE收敛路径、差分计算的不同分支）全部覆盖编译，触发编译器做全函数内联，去掉了所有不必要的动态检查和临时数组分配。
• 堆内存进入稳态：碎片化的无效内存被垃圾回收器批量回收整理后，内存分配不再需要频繁申请新的虚拟内存页，直接复用之前释放的连续内存块，刚好对应内存使用从剧烈波动转为平稳直线的表现。

逐轮耗时升高问题的解决方法 #

• 替换无类型数组：将initialize_particles中particles = []修改为particles = Vector{Particle}(undef, population)，消除动态分派的类型检查开销。
• 复用ODE求解器缓存：将cost_func中每次新建ODEProblem的逻辑，改用remake函数基于预初始化的problem对象更新参数和初始条件，避免每次重新初始化求解器的内部缓存。
• 消除多线程写竞争：将gbest的更新逻辑从多线程循环内部移出，改为每轮所有粒子计算完成后，统一遍历粒子的适应度更新全局最优值，避免无锁共享写带来的缓存同步开销。
• 预分配临时内存：PSO初始化时为所有粒子预分配固定大小的位置、速度数组，位置更新直接修改原数组内容，不再生成新数组；central_diff、get_error中的计算全部改用预分配的视图操作，减少临时内存分配量。

主动触发稳定全速运行状态的操作 #

• 提前触发编译预热：在正式运行50次PSO之前，先执行3~5次小规模PSO（小种群、少迭代轮次），手动调用cost_func遍历参数边界值触发所有代码路径编译，避免等运行20轮才进入优化状态。
• 主动整理堆内存：每轮PSO运行结束后执行GC.gc(false)，触发轻量化的堆压缩，将零散的空闲内存整理为连续块，让内存使用快速进入平稳状态，避免碎片化累积。
• 补全静态类型标注：为cost_func、ODE求解返回值等所有变量补充明确的类型断言，让编译器全程完成静态类型推断，消除动态分派的可能。
• 验证优化效果：调整完成后，单轮耗时应稳定在之前观察到的全速运行水平，不会再出现逐轮升高的趋势，就算增大种群规模和迭代次数，耗时增长也会保持线性，不会出现额外的性能增幅。

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