java7提供了Closeable接口,配合try-with-resource可以简化文件的读取操作。在没有try-with-resource之前。文件编写的规则模板如下
try{
xxx
}catch(Exception e){
xxx
}finally{
try{
ff.close()
}catch(Exception e){
xxx
}
}
为了保证功能正确。这个写法特别模板化,写的代码特别长。利用try-with-resource可以省略掉finally里的复杂过程。
try(xx){
xxx
}catch(Exception e){
xxx
}
虽然try-with-resource是给文件等资源做的一种精简写法的语法糖。但是他也可以应用在非资源的情况下,虽然 IOException 是无法省略的。
我们可以利用这个来让代码更好看,更安全。只要涉及到finally的部分。例如锁,在同一个代码块里完成是需要用finally来保证锁必须释放。避免后续因为代码问题导致的锁无法释放。我们选择用closeable来做改进。
public class LockAutocloseable implements Closeable {
private ReentrantLock reentrantLock = new ReentrantLock();
public void lock(){
reentrantLock.lock();
}
@Override
public void close() throws IOException {
System.out.println("unlock");
reentrantLock.unlock();
}
这里我们选择用一个类实现Closeable,并且包装ReentrantLock。在close里做unlock操作。那我们如何去使用这个类呢。
public static void main(String[] args) throws IOException {
try (LockAutocloseable lockAutocloseable = new LockAutocloseable()){
lockAutocloseable.lock();
}
}
这里是把这个IOException给抛出来了。实际应该有catch的过程的。
这里只是用ReentrantLock做个例子,在现实的案例中,zk的锁,redis的锁,都可以这样处理。
这个精简了finally的流程。看起来非常清爽。但是他的使用限制也很明显。那就是finally必须是当前的代码块释放。这里限制了灵活性。之前的分开的写法是可以做一些灵活的写法。适配一些特殊的场景。用了try-with-resource就舍弃了一定的灵活。
小结
- try-with-resource可以适配所有的finally的场景。
- try-with-resource可以让代码更精简。
- 使用 try-with-resource会舍弃一些灵活性。