扯什么 try-catch 性能问题？

我就是我 2023-10-15 15:07 6阅读 0赞

“yes，你看着这鬼代码，竟然在 for 循环里面搞了个`try-catch`，不知道`try-catch`有性能损耗吗？”老陈煞有其事地指着屏幕里的代码：

for (int i = 0; i < 5000; i++) {
        
         try {
        
             dosth
         } catch (Exception e) {
        
             e.printStackTrace();
         }
     }

我探过头去看了眼代码，“那老陈你觉得该怎么改？”

“当然是把`try-catch`提到外面啊！”老陈脑子都不转一下，脱口而出。

“你是不是傻？且不说性能，这代码的目的明显是让循环内部单次调用出错不影响循环的运行，你其到外面业务逻辑不就变了吗！”

老陈挠了挠他的地中海，“好像也是啊！”

“回过头来，catch 整个 for 循环和在循环内部 catch，在不出错的情况下，其实性能差不多。” 我喝一口咖啡不经意地提到，准备在老陈前面秀一下。

“啥意思？”老陈有点懵地看着我，“`try-catch`是有性能损耗的，我可是看过网上资料的！”

果然，老陈上钩了，我二话不说直接打开 idea，一顿操作敲了以下代码：

public class TryCatchTest {
        
    
        @Benchmark
        public void tryfor(Blackhole blackhole) {
        
            try {
        
                for (int i = 0; i < 5000; i++) {
        
                    blackhole.consume(i);
                }
            } catch (Exception e) {
        
                e.printStackTrace();
            }
        }
    
        @Benchmark
        public void fortry(Blackhole blackhole) {
        
            for (int i = 0; i < 5000; i++) {
        
                try {
        
                    blackhole.consume(i);
                } catch (Exception e) {
        
                    e.printStackTrace();
                }
            }
        }
    
    }

“BB 不如 show code，看到没，老陈，我把`try-catch`从 for 循环里面提出来跟在for循环里面做个对比跑一下，你猜猜两个差多少？”

“切，肯定 tryfor 性能好，想都不用想，不是的话我倒立洗头！”老陈信誓旦旦道。

我懒得跟他BB，直接开始了 benchmark，跑的结果如下：

![图片][a82c00835cc9602bc731848ffc16b19c.png]可以看到，两者的性能（数字越大越好）其实差不多：

*  fortry: 86,261(100359-14098) ~ 114,457(100359+14098)
 *  tryfor: 95,961(103216-7255) ~ 110,471(103216+7255)

我再调小(一般业务场景 for 循环次数都不会很多)下 for 循环的次数为 1000 ，结果也是差不多：

![图片][18a77ec56c50c2b86f582edf6dfe8ccf.png]老陈一看傻了：“说好的性能影响呢？怎么没了？”

我直接一个javap，让老陈看看，其实两个实现在字节码层面没啥区别：

> tryfor 的字节码

异常表记录的是 0 - 20 行，如果这些行里面的代码出现问题，直接跳到 23 行处理。

![图片][57659c15ffb4e5ee3604bbdc52fcdbea.png]

> fortry 的字节码

差别也就是异常表的范围小点，包的是 9-14 行，其它跟 tryfor 都差不多。

![图片][30261628d5974227488150392a029cde.png]

所以从字节码层面来看，没抛错两者的执行效率其实没啥差别。

“那为什么网上流传着`try-catch`会有性能问题的说法啊？”老陈觉得非常奇怪。

这个说法确实有，在《Effective Java》这本书里就提到了`try-catch`性能问题：

![图片][0ee3e90a79ef8fb754db490f03c009d9.png]

并且还有下面一段话：

![图片][fd7672f6f227c1f9fdefefef08f0331a.png]

正所谓听话不能听一半，以前读书时候最怕的就是一知半解，因为完全理解选择题能选对，完全不懂蒙可能蒙对，一知半解必定选到错误的选项！

《Effective Java》书中说的其实是不要用`try-catch`来代替正常的代码，书中的举例了正常的 for 循环肯定这样实现：

![图片][c935865fa3bf069681ed83f91f4b4fd2.png]

但有个卧龙偏偏不这样实现，要通过 `try-catch` 拐着弯来实现循环：

![图片][4167d4026f861f30bd2fe891fb121273.png]

这操作我只能说有点逆天，这两个实现的对比就有性能损耗了。

我们直接再跑下有`try-catch`的代码和没`try-catch`的 for 循环区别，代码如下：

![图片][ad1ca5879d6150ef7ebd3be0dd27c343.png]

结果如下：

![图片][03031a718f82e8b6820f8db1edef1629.png]

±差不多，直接看前面的分数对比，没有`ry-catch`的性能确实好些，这也和书中说的`try-catch`会影响 JVM 一些特定的优化说法吻合，但是具体没有说影响哪些优化，我猜测可能是指令重排之类的。

好了，我再总结下有关`try-catch`性能问题说法：

1.  `try-catch`相比较没`try-catch`，确实有一定的性能影响，但是旨在不推荐我们用`try-catch`来代替正常能不用`try-catch`的实现，而不是不让用`try-catch`。
2.  for循环内用 `try-catch`和用`try-catch`包裹整个 for 循环性能差不多，但是其实两者本质上是业务处理方式的不同，跟性能扯不上关系，关键看你的业务流程处理。
3.  虽然知道`try-catch`会有性能影响，但是业务上不需要避讳其使用，业务实现优先（只要不是书中举例的那种逆天代码就行），非特殊情况下性能都是其次，有意识地避免大范围的`try-catch`，只 catch 需要的部分即可（没把握全 catch 也行，代码安全执行第一）。

“好了，老陈你懂了没？”

“行啊yes，BB是一套一套的，走请你喝燕麦拿铁！” 老陈一把拉起我，我直接一个挣脱，“少来，我刚喝过咖啡，你那个倒立洗头，赶紧的！”我立马意识到老陈想岔开话题。

“洗洗洗，我们先喝个咖啡，晚上回去给你洗！”

晚上22点，老陈发来一张图片：

![图片][109ac5f4befeb9bb40007db5269caac2.png]

转自：https://mp.weixin.qq.com/s?\_\_biz=Mzg5NDM1ODk4Mw==&mid=2247557991&idx=2&sn=f6fc7c3a2e6a703032ba28b6577d5af8&chksm=c02367cff754eed947a033eb46abe3097f723492281ffcd81b8e0afc1c90291bdec9d5b3beec&mpshare=1&scene=1&srcid=0616AC4HPl0kdLFyevcAE0rM&sharer\_sharetime=1686912167023&sharer\_shareid=d0b161c46697d535cfb4da5dda6e322a\#rd

[a82c00835cc9602bc731848ffc16b19c.png]: https://img-blog.csdnimg.cn/img_convert/a82c00835cc9602bc731848ffc16b19c.png
[18a77ec56c50c2b86f582edf6dfe8ccf.png]: https://img-blog.csdnimg.cn/img_convert/18a77ec56c50c2b86f582edf6dfe8ccf.png
[57659c15ffb4e5ee3604bbdc52fcdbea.png]: https://img-blog.csdnimg.cn/img_convert/57659c15ffb4e5ee3604bbdc52fcdbea.png
[30261628d5974227488150392a029cde.png]: https://img-blog.csdnimg.cn/img_convert/30261628d5974227488150392a029cde.png
[0ee3e90a79ef8fb754db490f03c009d9.png]: https://img-blog.csdnimg.cn/img_convert/0ee3e90a79ef8fb754db490f03c009d9.png
[fd7672f6f227c1f9fdefefef08f0331a.png]: https://img-blog.csdnimg.cn/img_convert/fd7672f6f227c1f9fdefefef08f0331a.png
[c935865fa3bf069681ed83f91f4b4fd2.png]: https://img-blog.csdnimg.cn/img_convert/c935865fa3bf069681ed83f91f4b4fd2.png
[4167d4026f861f30bd2fe891fb121273.png]: https://img-blog.csdnimg.cn/img_convert/4167d4026f861f30bd2fe891fb121273.png
[ad1ca5879d6150ef7ebd3be0dd27c343.png]: https://img-blog.csdnimg.cn/img_convert/ad1ca5879d6150ef7ebd3be0dd27c343.png
[03031a718f82e8b6820f8db1edef1629.png]: https://img-blog.csdnimg.cn/img_convert/03031a718f82e8b6820f8db1edef1629.png
[109ac5f4befeb9bb40007db5269caac2.png]: https://img-blog.csdnimg.cn/img_convert/109ac5f4befeb9bb40007db5269caac2.png