如何优化包含大量if判断的老旧Java业务代码以提升运行性能？

现有代码核心问题 #

• 所有分支重复判断disturbance2 == 0，代码冗余度极高
• 300多行分散的if分支导致规则散落在代码各处，新增、修改规则需要修改业务逻辑，违反开闭原则
• 可读性差，排查问题需要逐行核对分支逻辑，维护成本极高
• 存在明显笔误：disturbance1和disturbance2取的是同一个字段值，还有分支里的bMeldung.getStoerungsartMde()大概率是变量名写错，优化时可以一并核对修正。

最适配当前场景的优化方案：查表法 #

你的所有if分支本质都是「条件匹配 → 传入对应参数调用checkWarnings」的固定模式，用查表法可以直接把300多行if逻辑压缩到10余行，同时大幅提升可维护性。

步骤1：抽象规则实体 #

把判断条件和对应要传入的PLS常量封装成规则类，JDK16+可以直接用record，低版本JDK用普通类加构造方法、getter即可：

// JDK16+ 规则实体
record DisturbanceRule(int targetDisturbance1, Integer targetDisturbance2, Integer targetDisturbanceType, int plsCode) {}

步骤2：预定义规则常量列表 #

把所有业务规则集中放到静态不可变列表里，所有规则一目了然：

private static final List<DisturbanceRule> DISTURBANCE_RULES = List.of(
    new DisturbanceRule(SPS1_20_PUFFER_EMPTY, 0, null, PLS_5_PUFFER_EMPTY),
    new DisturbanceRule(SPS1_30_STOPPERFL_LOCKED, 0, null, PLS_6_STOPPERFL_LOCKED),
    new DisturbanceRule(SPS1_40_DISTURBANCEFL, 0, DISTURBANCETYPE_SYSTEMDISTURBANCE_SHORT, PLS_3_SHORTDISTURBANCE_FL),
    new DisturbanceRule(SPS1_40_DISTURBANCEFL, 0, DISTURBANCETYPE_SYSTEMDISTURBANCE_LONG, PLS_4_SYSTEMMALFUNCTION_FL)
    // 剩余所有规则都按该格式补充到此处即可
);

规则字段传null表示不对该字段做校验，适配不需要判断disturbanceType的场景。

步骤3：替换原有if逻辑 #

原来的300多行if判断直接替换为遍历规则匹配：

int disturbance1 = bMessage.getDisturbanceSps1().intValue();
// 注意此处原代码两个变量取值相同，大概率是笔误，核对后修正disturbance2的取值逻辑
int disturbance2 = bMessage.getDisturbanceSps1().intValue();
int disturbanceType = bMessage.getDisturbanceType().intValue();

for (DisturbanceRule rule : DISTURBANCE_RULES) {
    if (rule.targetDisturbance1() != disturbance1) continue;
    if (rule.targetDisturbance2() != null && rule.targetDisturbance2() != disturbance2) continue;
    if (rule.targetDisturbanceType() != null && rule.targetDisturbanceType() != disturbanceType) continue;
    // 匹配到规则后执行业务逻辑
    checkWarnings(bMessage, rule.plsCode());
    // 如果业务规则是互斥的（匹配到一个就不再执行后续规则），打开下方break注释即可
    // break;
}

方案优势 #

• 代码量大幅压缩，逻辑清晰易读
• 所有规则集中管理，新增修改规则只需要调整DISTURBANCE_RULES列表，不需要动业务执行逻辑
• 性能优于逐行if判断，规则量大的情况下还可以按disturbance1分组存为Map<Integer, List<DisturbanceRule>>，匹配复杂度直接降到O(1)
• 完全兼容现有业务逻辑，不需要调整其他模块代码

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