日常标题党吸引读者,本篇文章主讲 try-with-resource
语法糖。如果大神已对这个语法糖了然于心请直接跳到结尾三连 :P 。好啦跟大家开个玩笑,请大家跟我一起了解今天的小知识点吧
应用场景
身为 Java 大神的各位肯定避免不了使用各式各样需要关闭的 Stream 或 Client 吧。例如 FileInputStream、HTTPClient 之类的。那么大家肯定会遇到以下恶心的代码
File file = new File("/root/usr/file.txt"); FileInputStream fileInputStream = null; try { fileInputStream = new FileInputStream(file); System.out.println("fileInputStream = " + fileInputStream); } catch (FileNotFoundException e) { log.error("error", e); } finally { if (null != fileInputStream) { try { fileInputStream.close(); } catch (IOException e) { e.printStackTrace(); } } }
此处使用 System.out.println
来代替模拟的业务操作,在咱们这种代码洁癖的人眼中,这个 finally 简直是毒瘤!那么怎么把这坨恶心又难看的代码给优化掉呢?其实 Java 已经帮我们想好了。
代码改造
那么究竟是怎么操作的呢,这就要引入我们今天的重点:try-with-resource
我们先看效果,再说原理。针对上述一大坨代码,可以改为如下一般简洁的几行。这样可以让程序员将更多的心思放在业务逻辑上,而不是异常处理和资源关闭:
File file = new File("/root/usr/file.txt"); try (FileInputStream fileInputStream = new FileInputStream(file)) { System.out.println("fileInputStream = " + fileInputStream); } catch (IOException e) { log.error("error", e); }
那么读者可能会问了,我们不用去管关闭资源,那这些事情谁来干了?毫无疑问当然是虚拟机!我们跟入 FileInputStream
这个类并查看他的父类 InputStream
会发现,这个类实现了一个名为 Closeable
接口,而这个接口又是继承了 java.lang
包中的 AutoCloseable
接口。这个接口只有一个方法,那就是 close
方法。InputStream
中实现了这个方法,但是方法体是空的,真正的执行者是他的子类 FileInputStream
,FileInputStream
中重写了这个 close 方法来实现资源的关闭。
有的读者朋友跟到这里可能已经蒙了,说一千道一万,继承这个实现那个,那到最后到底谁关的。或者说,到底是谁执行的呢?那么大家请跟我进入源码时刻!
实现原理
说是源码其实有点惭愧,这里没啥源码可讲。只不过是虚拟机在编译的时候给他把 finally 加上了而已。我们来看下反编译之后的类
是不是有人开始砸桌子大呼上当了?是的,这里根本没啥蹊跷的,就是 JVM 把你不想写的代码给你添上了而已。至于他是怎么改的,各位大佬请自行翻阅 JVM 源码,小弟这里帮不上了。
题外话
基本看到这里的都是真爱了,其实上面那些东西网上都讲烂了。那我就多几句嘴,说上几个关于 try-with-resource
的小技巧和有意思的东西吧。
1、IDEA 自动生成
如果有细心的朋友,其实会发现有的IDE (如 IDEA)已经支持一键使用 try-with-resource
包裹了。例如下图:
2、自行创建类实现 AutoClosable 接口
其实,我们使用 try-with-resource
语法糖的场景不仅限于各类资源的关闭。我们也可以自己定义一个类,只要他实现了 AutoClosable
接口,也能用 try-with-resource
语法去包裹,并让 JVM 为你填上 finally 代码块。例如如下代码:
public class CustomAutoCloseImpl implements AutoCloseable{ public void run() { // todo biz code } @Override public void close(){ System.out.println("close execute!!"); }}public class AutoCloseTest { public static void main(String[] args) { try (CustomAutoCloseImpl customAutoClose = new CustomAutoCloseImpl()) { customAutoClose.run(); } catch (Exception e) { System.out.println(e.getMessage()); } }}
这个 close
方法一定会给你执行掉。例如有一个场景,这个人访问了网站,无论业务操作是否成功都要给接口调用次数加 1。这个加 1 的操作,就可以放在 close
中,然后调用的时候使用 try-with-resource
语法糖,避免冗余代码判断。当然这里举的例子可能不太恰当,只当是给大家提供一个别样的使用 try-with-resource
的思路(我知道这里肯定有人说这样使用会违背这个语法糖的设计初衷,但我想说的是,思想是活的。没必要把自己定死)
3、try-with-resource 一定要处理异常嘛?
这一点也是我的突发奇想,大家可以看一下下面的代码猜一下运行结果
public class CustomAutoCloseImpl implements AutoCloseable{ public void run() { throw new RuntimeException("I suppose to throw an exception!!"); } @Override public void close(){ System.out.println("close execute!!"); }}public class AutoCloseTest { public static void main(String[] args) { try (CustomAutoCloseImpl customAutoClose = new CustomAutoCloseImpl()) { customAutoClose.run(); } catch (Exception e) { System.out.println(e.getMessage()); } System.out.println("----------------------"); try (CustomAutoCloseImpl customAutoClose = new CustomAutoCloseImpl()) { customAutoClose.run(); } }}
大家在心里猜一下执行结果吧(其实看懂上面反编译代码的这里一下就能猜对的~)。
看着执行结果有几个有意思的点。大家发现了吗,是先执行的 close
方法再去执行的 catch
内部方法块。至于为什么,去看看上面反编译的结果大家就懂啦。还有个有意思的地方,try-with-resource
是可以不用 catch
的哦~ 当然,虽然 close
方法也会给你执行,但是异常该抛还是会给你抛出来的。以后使用的时候,这里也是一个可以利用的地方哦,比如方法内部抛一个自定义异常,外面不捕捉扔给全局异常处理器去处理之类的~
4、try-with-resource 可以包裹多个资源哦
直接上代码吧
public static void main(String[] args) { try (CustomAutoCloseImpl customAutoClose = new CustomAutoCloseImpl(); FileInputStream fileInputStream = new FileInputStream(new File("")); FileOutputStream fileOutputStream = new FileOutputStream(new File("")); ) { // todo biz code customAutoClose.run(); fileInputStream.read(); fileOutputStream.flush(); } catch (Exception e) { System.out.println(e.getMessage()); } }
定义多资源的反编译 class 文件很有意思哦,大家可以自己去编译了看看~
总结
任何东西都有它的利害两面,最后总结说一下我认为的优缺点吧:
优点
- 最大的好处是不用写 finally 了这不用说了吧
- 提高了程序员针对业务的关注性,不用写着业务代码还要去考虑关闭没关闭的问题
- 减少了 漏写、忘写 等错误产生的各类内存泄漏问题,毕竟虚拟机大佬还是靠谱的
- 增加了代码的可玩儿性
缺点
- 如果想在
close
方法抛出异常时做点事情,怕是做不到。 - 隐藏起来的东西很可能会引出怎么查也查不到的问题(当然这种情况的出现应该是极极极极少的)
- 让程序员更懒了,嗯这是个很大的缺点!
因为身边的有些大佬竟然还不知道这个语法糖,所以突发奇想写出来。