背景
最近客戶端在線上大大小小的出現了很多問題，尤其是線上的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層拋出的異常
其實這種情況無法捕獲的原因跟上面的跨線程無法捕獲的原因在本質上是一致的，因為在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));
}
執行結果
一段代碼加上try catch后代碼的執行時間沒有明顯的變化，得出的結論和之前的分析結果基本一致，那我們是不是可以得出結論說try catch對性能沒有影響呢？答案是否定的，在后續的資料查閱過程中得知，try塊會阻止java編譯器優化（例如重排序等），這在理論上是會降低性能的，但是這個實驗條件比較苛刻，所以這里我沒有通過實驗去證明。
總結
try catch對代碼的性能是有影響的，但是這種影響是可控的，例如我們在實際的開發過程中try代碼塊的范圍盡量收斂，這對性能造成的影響幾乎是可以忽略的，當然你把“全世界”try起來，這個影響還是很大的！
