背景
最近客户端在线上大大小小的出现了很多问题，尤其是线上的crash数量增长明显，在求生欲的驱使下，大家默契的确保每一行代码都行驶在try...cache中，从此整个项目的画风变了，代码里到处充斥着弯弯曲曲的大括号 "}" ，但是不得不说的是崩溃率神奇的下降了。
通过分析线上崩溃数据我把crash分为以下几种情况：
- 空指针（null）导致crash
- Native异常导致
- 内存泄漏导致
- 三方SDK导致
- 其他
其中第1条空指针导致的crash占比相对较高，终其原因是接口数据在反序列化成Java对象的时候某些字段可能为空，在业务开发过程中如果访问了这些null对象又没有进行判空就会导致NullPointException产生，要避免这个问题只能在访问对象属性之前进行判空或者加上try cache。对比判空try catch可以简单粗暴的解决这个问题，这也是崩溃率下降的最直接原因。这样做虽然问题得到了一定程度的解决，但是也带来了很多副作用。首先代码的可读性下降了，除此之外使用try catch可以解决所有的crash问题吗？会不会有性能问题？有没有更优雅的解决办法？为此我做了本期关于try catch的调研与总结。
无法捕获场景
try catch可以捕获所有异常吗？一段代码是不是加上try catch就可以高枕无忧了？没那么简单我总结了一下大约有以下情况是捕获不到的
1. 捕获范围不匹配
例如以下代码就会导致抛出的异常无法被捕获
private static List<Object> list = new ArrayList<>();
try {
if (BuildConfig.DEBUG) {
while (true){
list.add(new int[1024*1024]);
}
}
} catch (Exception e) {
e.printStackTrace();
}
上述代码会产生OutOfMemoryError，但是我们catch的是Exception所以无法被捕获到，如果我们改成catch Error这个异常就可以被捕获，Java中的异常体系如下：
- Throwable: Java中所有异常和错误类的父类。只有这个类的实例（或者子类的实例）可以被虚拟机抛出或者被java的throw关键字抛出。同样，只有其或其子类可以出现在catch子句里面。
- Error: Throwable的子类，表示严重的问题发生了，而且这种错误是不可恢复的。
- Exception: Throwable的子类，应用程序应该要捕获其或其子类（RuntimeException例外），称为checked exception。比如：IOException, NoSuchMethodException...
- RuntimeException: Exception的子类，运行时异常，程序可以不捕获，称为unchecked exception。比如：NullPointException.
2. 跨线程
try {
new Thread(){
@Override
public void run() {
super.run();
throw new RuntimeException();
}
}.start();
} catch (Exception e) {
e.printStackTrace();
}
上述实例代码的Exception就无法被捕获，这是因为try catch只能捕获当前线程的VM Method Stack中的异常。
3. Native层抛出的异常
image-20201221182135104.png
其实这种情况无法捕获的原因跟上面的跨线程无法捕获的原因在本质上是一致的，因为在JVM中Java成的 Method Stack 和 Native 层的Method Stack是相互独立的（如上图所示），所以Java层的try catch无法捕获到Native层产生的异常。
对性能的影响
要验证try catche对性能影响我们可以在一段代码在加上try catche后验证：
- 编译结果中的
jvm指令有没有增加 - 执行时间有没有增加
首先我们来看编译结果中的jvm指令有没有变化，为此我设计了以下简单的代码片段来验证try catche对编译结果jvm指令的影响。
源码一和源码二的唯一区别就是在
hello方法加上了try catch。
源码一：
public class SimpleTry {
public static void main(String[] args){
hello();
}
private static void hello(){}
}
字节码一：
1 Compiled from "SimpleTry.java"
2 public class SimpleTry {
3 public SimpleTry();
4 Code:
5 0: aload_0
6 1: invokespecial #1// Method java/lang/Object."<init>":()V
7 4: return
8
9 public static void main(java.lang.String[]);
10 Code:
11 0: invokestatic #2// Method hello:()V
12 3: return
13 }
源码二：
public class SimpleTry {
public static void main(String[] args){
try {
hello();
} catch (Exception e) {
e.printStackTrace();
}
}
private static void hello(){}
}
字节码二：
1 Compiled from "SimpleTry.java"
2 public class SimpleTry {
3 public SimpleTry();
4 Code:
5 0: aload_0
6 1: invokespecial #1 // Method java/lang/Object."<init>":()V
7 4: return
8
9 public static void main(java.lang.String[]);
10 Code:
11 0: invokestatic #2 // Method hello:()V
12 3: goto 11
13 6: astore_1
14 7: aload_1
15 8: invokevirtual #4 // Method java/lang/Exception.printStackTrace:()V
16 11: return
17 Exception table:
18 from to target type
19 0 3 6 Class java/lang/Exception
20 }
通过对比字节码一和字节码二我们可以看出在不发生异常的情况下两者的jvm指令是一致的，所以就这段代码来说两者的理论性能是没有差异的，下面再通过代码打印下一段代码加上try catch前后的执行时间变化验证下我们的结论。
//无try catch
private void tryCount(){
long start = System.nanoTime();
int count = 0;
for (int i = 0; i < 100; i++) {
count++;
}
System.out.println("tryCount:"+count +"time:"+(System.nanoTime() - start));
}
//有try catch
private void tryCountWithException(){
long start = System.nanoTime();
int count = 0;
for (int i = 0; i < 100; i++) {
try {
count++;
} catch (Exception e) {
}
}
System.out.println("tryCountWithException:"+count+"time:"+(System.nanoTime() - start));
}
执行结果
image-20201221170216869.png
一段代码加上try catch后代码的执行时间没有明显的变化，得出的结论和之前的分析结果基本一致，那我们是不是可以得出结论说try catch对性能没有影响呢？答案是否定的，在后续的资料查阅过程中得知，try块会阻止java编译器优化（例如重排序等），这在理论上是会降低性能的，但是这个实验条件比较苛刻，所以这里我没有通过实验去证明。
总结
try catch对代码的性能是有影响的，但是这种影响是可控的，例如我们在实际的开发过程中try代码块的范围尽量收敛，这对性能造成的影响几乎是可以忽略的，当然你把“全世界”try起来，这个影响还是很大的！
网友评论