关于 “Try...Catch” 理解与总结

背景

最近客户端在线上大大小小的出现了很多问题,尤其是线上的crash数量增长明显,在求生欲的驱使下,大家默契的确保每一行代码都行驶在try...cache中,从此整个项目的画风变了,代码里到处充斥着弯弯曲曲的大括号 "}" ,但是不得不说的是崩溃率神奇的下降了。

通过分析线上崩溃数据我把crash分为以下几种情况:

  1. 空指针(null)导致crash
  2. Native异常导致
  3. 内存泄漏导致
  4. 三方SDK导致
  5. 其他

其中第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后验证:

  1. 编译结果中的jvm指令有没有增加
  2. 执行时间有没有增加

首先我们来看编译结果中的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起来,这个影响还是很大的!

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 219,366评论 6 508
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 93,521评论 3 395
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 165,689评论 0 356
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 58,925评论 1 295
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 67,942评论 6 392
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 51,727评论 1 305
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 40,447评论 3 420
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 39,349评论 0 276
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,820评论 1 317
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,990评论 3 337
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 40,127评论 1 351
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,812评论 5 346
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 41,471评论 3 331
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 32,017评论 0 22
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 33,142评论 1 272
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 48,388评论 3 373
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 45,066评论 2 355

推荐阅读更多精彩内容