阿里小哥带你玩转JVM：揭秘try-catch-finally在JVM底层都干了些啥？
点击上方 石杉的架构笔记 ，右上选择“ 设为星标 ”
每日早8点半，精品技术文章准时送上
往期文章
BAT 面试官是如何360°无死角考察候选人的（上篇）
每秒上万并发下的Spring Cloud参数优化实战
分布式事务如何保障实际生产中99.99%高可用
记一位朋友斩获 BAT 技术专家Offer的面试经历
亿级流量架构系列之如何支撑百亿级数据的存储与计算
作者：李瑞杰
目前就职于阿里巴巴，狂热JVM爱好者
让我们准备一个函数:
然后，反编译他的字节码：
首先我们介绍异常表：在编译生成的字节码中，每个方法都附带一个异常表。
异常表中的每一个条目代表一个异常处理器，并且由 from 指针、to 指针、target 指针以及所捕获的异常类型构成。这些指针的值是字节码索引用以定位字节码。
下图就是我特别指出的JVM字节码中的异常表部分。
我们来分析一下这几个语句的执行流程，首先执行：
这相当于执行：
再来：
上图相当于执行
有人问： try去哪了？
我马上就要介绍。此时idiv执行完就有异常了，有异常了先找异常表。
我再贴一下异常表， 他是怎么搜索的呢？
当程序触发异常时，Java 虚拟机会从上至下遍历异常表中的所有条目。
当触发异常的字节码的索引值在某个异常表条目的监控范围内，Java 虚拟机会判断所抛出的异常和该条目想要捕获的异常是否匹配。
如果匹配，Java 虚拟机会将控制流转移至该条目 target 指针指向的字节码。
我们看 ，是第四个索引指向的字节码出了问题，显然，此时应该匹配红线这一条记录， 从而跳转到第14个索引的字节码。 
我们看他怎么做的？
new出一个RuntimeException并抛出，它就是
这一句，按照我们刚才的流程，此时依然需要找到这个RuntimeException在哪个异常表的条目中
此时匹配到异常表的条目，跳转到字节码索引23
继续抛出RuntimeExcpetion，可以注意到 这实际上对应了
这个语句，于是我们可以知道，在三个都出现异常的情况下，实际上最终向外抛出的异常是finally里面的异常。
可以看到当31索引处调用athrow语句抛出异常时，此时异常表没有任何一个条目能够匹配该异常，此时怎么办呢？
如果遍历完所有异常表条目，Java 虚拟机仍未匹配到异常处理器，那么它会弹出当前方法对应的 Java 栈帧，并且在调用者中重复上述操作。
在最坏情况下，Java 虚拟机需要遍历当前线程 Java 栈上所有方法的异常表。
事实上分析以上的整体的全部语句你可以发现， jvm层面有真正的finally吗？
没有
现在的做法是，复制 finally 代码块的内容，分别放在 try-catch 代码块所有正常执行路径以及异常执行路径的出口中。无论是否出现异常，确保一定会执行finally语句。
刚才catch出了异常，依然执行finally语句就可以发现这一点。至于其他路径，大家可以自行验证。我就在这里抛砖引玉了。
至于为什么2-6发生任何异常都跳转到23？大家可以自己想一下这个问题。
我就提示一点 2-6 target为14的条目代表的catch是不能捕获所有异常的，但是你要确保finally的语句能够执行。而2-6恰巧是try语句块的内容。23这个索引恰巧是finally语句的一份复制。
END
划至底部，点击“ 在看 ”，是你来过的仪式感！
推荐阅读：
-
简历写了会Kafka，面试官90%会让你讲讲acks参数对消息持久化的影响！
-
面试最让你手足无措的一个问题：你的系统如何支撑高并发？
-
Java高阶必备：如何优化Spring Cloud微服务注册中心架构？
-
高并发场景下，如何保证生产者投递到消息中间件的消息不丢失？
-
从团队自研的百万并发中间件系统的内核设计看Java并发性能优化！
-
如果20万用户同时访问一个热点缓存，如何优化你的缓冲架构？
更多文章：
-
2018年原创汇总
-
2019年原创汇总（持续更新）
-
爆款推荐
-
面试专栏
欢迎长按下图关注公众号 石杉的架构笔记
BAT架构经验倾囊相授
正文到此结束
热门推荐
相关文章
近期评论
-
文章和留言都翻到11页了 没有OOM
-
-
朋友，翻页到11页，及以后，会出现OOM，无法访问
-
-
搞个gitee的项目
-
-
版本号是多少，你可以下载哪个代码仓库，jdk选1.8 直接跑就行
-
-
-
Loading...
![[HBLOG]公众号](https://www.liuhaihua.cn/img/qrcode_gzh.jpg)
