OptaPlanner：Join时过滤与Join后过滤的差异及Joiners执行顺序问题

一、两种写法的语义与性能差异 #

语义层面 #

两种写法的最终语义完全一致，都是保留两个Entity流关联后满足myBiPredicate条件的配对结果。

性能层面 #

两者存在显著性能差距：

• 写法一（join时传入Joiners.filtering(myBiPredicate)）：在关联两个流的过程中就直接过滤不满足条件的配对，避免生成大量无效的中间关联结果（比如全量笛卡尔积），内存占用和计算开销都更小。
• 写法二（先join再filter）：会先生成两个流的全量关联结果（所有可能的配对），再对这个大结果集进行过滤。当数据集规模较大时，中间结果集的体积会非常庞大，导致内存消耗剧增、过滤阶段计算量大幅上升，性能远不如写法一。

二、Joiners的执行顺序与剪枝建议 #

执行顺序 #

Joiners的参数是按照传入的顺序依次执行的，库的实现会严格遵循参数列表的顺序来应用各个Joiner操作。

剪枝建议 #

强烈建议把能大量剪枝（即过滤掉大部分无效数据）的过滤器放在参数列表的靠前位置。原因很直接：越早过滤掉无效数据，后续的Joiners操作需要处理的数据量就越小，整体的计算开销和内存占用都会显著降低，性能提升效果会非常明显。比如一个能过滤掉90%数据的谓词，放在第一个位置比放在最后，能让后续所有操作都只处理剩下10%的数据。

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