作为一名程序员,求职面试时,关于编码的问题时常会遇到。
张工是一名java程序员,最近到某知名互联网公司面试,面试官提了这样的一个问题:
这段代码从代码整洁角度看,有没有优化的空间?如何优化?
public static void writeFile(String str) {
FileWriter fw = null;
try {
fw = new FileWriter("e://1.txt", true);
fw.write(str);
} catch (Exception ex) {
ex.printStackTrace();
} finally {
if (fw != null) {
try {
fw.close();
} catch (IOException e) {
e.printStackTrace();
}
}
}
}
张工仔细看了一下程序,发现程序本身并没有问题,从代码整洁角度看,还算比较规范。
于是说,“没有问题”
面试官:你平时也是这么写的吗?
张工:是的
面试官:你有没有觉得这段代码可读性很一般呢?
张工:还好。
面试官:那你了解jdk1.7新特性吗?
张工:这个我了解啊。
面试官:我问的这个就是和这个相关啊。
被面试官这么一说,张工都不好意思了。
其实面试官问这个问题无非就是考察两点:
对Jdk1.7新特性是否了解
try()...catch()的用法,关闭代码的逻辑比较冗长
在JDK1.7前,通常我们使用try...catch()来捕获异常的,如果遇到类似IO流的处理,一般是在finally部分关闭IO流,但在JDK1.7后,Java 7 的编译器和运行环境支持新的 try-with-resources 语句,称为 ARM 块(Automatic Resource Management) ,自动资源管理。写在()里面的流对象对应的类都实现了自动关闭接口AutoCloseable。
AutoCloseable接口位于java.lang包下,从JDK1.7开始引入。
在JDK1.7之前,我们通过try{} finally{} 在finally中释放资源。在finally中关闭资源存在以下问题:
开发者需要手动写代码做关闭的逻辑;
有时候可能会忘记关闭一些资源,导致内存泄漏;
关闭代码的逻辑比较冗长,代码可读性差。
在JDK1.7后,对于实现AutoCloseable接口的类的实例,将其放到try后面(我们称之为:带资源的try语句),在try结束的时候,会自动将这些资源关闭(调用close方法)。
带资源的try语句的3个关键点:
由带资源的try语句管理的资源必须是实现了AutoCloseable接口的类的对象。
在try代码中声明的资源被隐式声明为fianl。
通过使用分号分隔每个声明可以管理多个资源。
格式:
try (创建流对象语句,如果多个可以使用';'隔开) {
// dosomething
} catch (IOException e) {
e.printStackTrace();
}
}
JDK1.7后,使用关闭方式,则不需要在finally中进行数据关闭。将资源关闭不需要写代码操作
这些可关闭的资源必须实现 java.lang.AutoCloseable 接口
比如我们将FileWriter放置try()中
public static void writeFile(String str) {
try (FileWriter fw = new FileWriter("e://1.txt", true)) {
fw.write(str);
} catch (Exception e) {
e.printStackTrace();
}
}
我们跟进去看FileWriter.发现继承至OutputStreamWriter
点进去看OutputStreamWriter.发现实现了Writer
再点进去看Writer.发现实现了Closeable
点进去看Closeable.发现实现了AutoCloseable
发现Closeable 继承至AutoCloseable .那么即满足了带资源关闭的基本要求。当try 中的{ } 执行完后,将会自动关闭资源。
由于笔者水平有限,文中纰漏之处在所难免,权当抛砖引玉,不妥之处,请大家批评指正。
近期推荐
面试官:你都工作三年了,怎么如何对数据匹配规则都没有掌握
更多惊喜,请长按二维码识别关注