最近处理的sonar问题，近一半都是资源未关闭的问题，sonar提示我们可以使用try-with-statement来解决这类问题，我尝试和总结了如下：
这个是用来替代繁琐的try catch finnally
它会自动close 所有实现了java.lang.AutoCloseable接口的资源
写法是在try后面跟着一个小括号，把资源的声明代码写进去就ok了
try (BufferedReader br =
new BufferedReader(new FileReader(path))) {
return br.readLine();
}catch(IOExcepton e){
}
这个里面br就会在使用完毕后自动关闭，比如抛出异常，或是try代码块执行完毕的时候，会自动执行close，妈妈再也不用担心我们的close
这个小括号里面可以声明一个或是多个资源变量
这个写法等价于
BufferedReader br = new BufferedReader(new FileReader(path));
try {
return br.readLine();
} catch(){
}
finally {
// do br.close() 先简单这样理解，编译器对close抛出的异常做了move-exception操作这点无法用代码表述出来，详见后文 }
需要注意一点，它对Exception的抛出做了更友好的改进，通常在
//伪代码
try{
a = ClosableSteam()
} catch(Exception e){
}finnaly{
close()
}
里面如果catch了异常后在执行close的时候又抛出了异常，系统会抛出close时候的异常，这不利于定位问题，所以在使用try-with-statement里面引入了SupressedException的概念，相当于原代码段被处理成了如下方式
TryStudy tryStudy = null;
try{
tryStudy = new TryStudy();
System.out.println(tryStudy);
}catch(Throwable suppressedException) {
if (tryStudy != null) {
try {
tryStudy.close();
}catch(Throwable e) {
e.addSuppressed(suppressedException);
throw e;
}
}
throw suppressedException;
}
这样抛出的异常其实就是原异常，有助于我们定位真实的Exception点，这个原异常会在
try(){ //try-with-statement
}catch(Exception e){
}
这里的e里面拿到，如果一定要拿close时候抛的异常，那么在Exception中getSupressedException就可以了
抛出来的异常大概会长这样
java.io.IOException: doSomething IOException
at sg.bigo.lijiangyan.testtrywithstatement.MyClosableClass.doSomething(MyClosableClass.java:11)
at sg.bigo.lijiangyan.testtrywithstatement.MainActivity.onCreate(MainActivity.java:19)
at android.app.Activity.performCreate(Activity.java:7149)
at android.app.Activity.performCreate(Activity.java:7140)
at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1288)
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:3017)
at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:3172)
at android.app.servertransaction.LaunchActivityItem.execute(LaunchActivityItem.java:78)
at android.app.servertransaction.TransactionExecutor.executeCallbacks(TransactionExecutor.java:108)
at android.app.servertransaction.TransactionExecutor.execute(TransactionExecutor.java:68)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1906)
at android.os.Handler.dispatchMessage(Handler.java:106)
at android.os.Looper.loop(Looper.java:193)
at android.app.ActivityThread.main(ActivityThread.java:6863)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:537)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:858)
Suppressed: java.io.IOException: close IOException
at sg.bigo.lijiangyan.testtrywithstatement.MyClosableClass.close(MyClosableClass.java:16)
at sg.bigo.lijiangyan.testtrywithstatement.MainActivity.onCreate(MainActivity.java:20)
... 15 more
可以看到这里跟了一个Suppressed部分
当然这里也要注意有坑，由于这个语法糖是在java7引入的，如果androidminsdk低于19，就不能用，但是android在支持java8后使用desugar解决了这个问题，所以我们的项目中可以愉快的使用
当然，还有更坑，要注意这是编译器帮我们加的，假如包装类在close中还做了其余可能抛出异常的代码，而这些代码在close之前，依旧可能发生泄露，例如，GZIPOutputStream https://juejin.im/entry/57f73e81bf22ec00647dacd0
try (FileInputStream fin = new FileInputStream(new File("input.txt"));
GZIPOutputStream out = new GZIPOutputStream(new FileOutputStream(new File("out.txt")))) {
}
GZIPOutputStream里面的close会调用flush之后再调用close，但是flush会抛出异常，而编译器帮我们加的代码是fin和out的close，所以这种情况发生的时候out里面被包装的那个FileOutputStream发生了泄露，正确的做法应该是单独为每个流声明
try (FileInputStream fin = new FileInputStream(new File("input.txt"));
FileOutputStream fout = new FileOutputStream(new File("out.txt"));
GZIPOutputStream out = new GZIPOutputStream(fout)) {}
编译器会帮我们close fin，fout，以及out，这样所有资源就可以正确的关闭了
