Java 求解如何优化 100 个 if 判断？

[whereisgungun]

需求是这样的：
上游服务调用接口（ TCP 协议，用 netty 做了服务端，上游是客户端）发来报文，这个报文里面会有 35 个属性，我们简单定义这 35 个属性为 A 、B 、C 、D....然后每个属性的值为 a 、b 、c 、d....现在有接近 100 个模板，然后我们的功能就是要根据报文来确定要用哪一个，重点是这 100 个模板是没有规律的。

比如：
if(a==1 && b==2) {return "模板 1";}
if(c.length==1 && d.equals("xxx")) {return "模板 2";}
...
也就是说，会有 100 个 if 判断来确定此次调用的报文对应哪个模板，而且报文是不冲突的，35 个属性的值只要命中其中一个模板，其他的就都不符合，都是互斥的。（算是 CompletableFuture 的 anyOf 方法。）

现在暂时找不出这 100 个 if 里面有什么具体的规律，35 个属性也没有。求问各位大神有什么好的思路优化吗？线程池 or 中间件？

PS：作为最底层的外包，也没法要求上游能做什么改动了。。他们是一个老旧的银行系统，以前也是用的一个一个判断来着，现在把项目丢给我们了。。

[yolee599]

建表，把所有需要判断的条件做成列，所有的处理函数作为行。一行一行遍历，每一行遍历所有列，如果有空列，则不做这列的判断，有符合条件的行就执行该行的处理函数。这样看起来比较好看，就是会损失一点点性能

[ipwx]

楼上已经提到过了，用统计重新排列 if 的顺序可以提速。更近一步，可以通过命中概率构建一个二叉树，类似于霍夫曼树。然后自动生成嵌套的 if 代码。这样速度是最快的。

https://zhuanlan.zhihu.com/p/54714101

[xlzyxxn]

无非丑了点，不要嘲笑别人，也不要怕被别人嘲笑，switch 表结构和 if 条件分支预测是能快，但优雅的代码是建立在解决业务问题之上的，不那么优雅的代码往往是因为复杂的业务问题。

[weixiangzhe]

我也觉得拆成 责任链 比较好

[forbreak]

如果是为了性能那么就不用优化了。 提升性能觉对不会需要你再去优化这个 if 的性能。 因为肯定有比这个地方更慢的东西值得你去优化。要是为了优化代码结构还值得去折腾折腾。

[PythonYXY]

别重构了，到时候屎山崩了你要负责的

[GLee9507]

责任链模式+1
@weixiangzhe

[BQsummer]

这种场景 if 是最快的了

[TArysiyehua]

100 个 if 完全没必要优化，效率贼高，上面说的提高命中率和加设计模式能提高你写代码的技术，这个倒是真的。但是对性能是几乎没有帮助的。

[WhiteDragon96]

把所有对应关系放 map 里面

[xuelu520]

这种真没办法，必须这么多 if 每个来处理，顶多按#9 楼的说法，高频放上面。

[kaf]

写一百个枚举或者 key-value 放 map 里

[XXWHCA]

判断规则都不一样，这个是没办法改，上面说用 map ，枚举的都没有好好审题，#9 才是最实际的，高频放上面

[ScepterZ]

你这个是有优先级的，不能直接改顺序，才 100 个 if 没啥好优化的，不差这点性能
你要是优化代码结构还可以搞一下

[lazyfighter]

所有的优化都是由繁化简，楼主首要前提是理解这 30 多个参数的含义，以及他们是怎么组合的，if 能有什么性能问题？

[newmlp]

为啥要优化，100 个 if 构不成性能问题吧

[v2eb]

性能应该不成问题。
主要代码长, 逻辑难梳理, 所以问题应该是：
如何以可读性更高的方式优化 100 个 if 嵌套？

[winglight2016]

用 switch 吧，onehotencode 编码一下就可以了

[yinft]

第一反应是放 map 做映射

[xuanbg]

这么多条件，唯有查表解君愁。