在Java中，構造異常物件是”十分”耗時的，其原因是在預設情況下，建立異常物件時會呼叫父類Throwable的fillInStackTrace()方法生成棧追蹤資訊，JDK中的原始碼如下：

public synchronized Throwable fillInStackTrace() {
        if (stackTrace != null ||
            backtrace != null /* Out of protocol state */ ) {
            fillInStackTrace(0); // native方法
            stackTrace = UNASSIGNED_STACK;
        }
        return
 
 this;
    }

在我自己做的測試中，new一個帶有棧追蹤資訊的Exception物件要比建立不帶追蹤資訊的物件慢50倍以上。雖然列印呼叫棧能夠精確定位到錯誤發生的程式碼所在行，但我們可以考慮一下，真的有必要讓所有異常都生成這些資訊嗎？

我們在開發業務系統的過程中一般都會使用異常機制來實現錯誤處理邏輯，這些異常通常都可以分成兩大類：

• 業務異常
  這些是我們自定義的、可以預知的異常，丟擲這種異常並不表示系統出了問題，而是正常業務邏輯上的需要，例如使用者名稱密碼錯誤、引數錯誤等。

• 系統異常
  往往是執行時異常，比如資料庫連線失敗、IO失敗、空指標等，這種異常的產生多數表示系統存在問題，需要人工排查定位。

其實對於業務異常，我們只需要簡單的知道一個描述問題的字串即可，棧追蹤資訊對我們的意義並不大。而對於系統異常，追蹤資訊才是排查錯誤不可或缺的參考。因此我們可以想辦法控制一下，建立業務異常時不生成呼叫棧追蹤資訊以降低開銷，系統異常則正常生成。

其實方法非常簡單，在我們自定義異常時，只需要重寫父類的一個帶有4個引數的構造方法即可，此方法在Exception和RuntimeException類中都存在：

protected RuntimeException(String message, Throwable cause,
                               boolean
 
 enableSuppression,
                               boolean writableStackTrace) {
        super(message, cause, enableSuppression, writableStackTrace);
    }

這幾個引數的意義如下：

• message
  異常的描述資訊，也就是在列印棧追蹤資訊時異常類名後面緊跟著的描述字串
• cause
  導致此異常發生的父異常，即追蹤資訊裡的caused by
• enableSuppress
  關於異常掛起的引數，這裡我們永遠設為false即可
• writableStackTrace
  表示是否生成棧追蹤資訊，只要將此引數設為false, 則在構造異常物件時就不會呼叫fillInStackTrace()

例如，業務異常可以這樣定義：

public class XXXException extends RuntimeException {
    /**
     * 僅包含message, 沒有cause, 也不記錄棧異常, 效能最高
     * @param msg
     */
    public XXXException(String msg) {
        this(msg, false);
    }

    /**
     * 包含message, 可指定是否記錄異常
     * @param msg
     * @param recordStackTrace
     */
    public EngineException(String msg, boolean recordStackTrace) {
        super(msg, null, false, recordStackTrace);
    }

    /**
     * 包含message和cause, 會記錄棧異常
     * @param msg
     * @param cause
     */
    public EngineException(String msg, Throwable cause) {
        super(msg, cause, false, true);
    }
}

即通過使用父類中4引數的構造方法精確控制異常類的行為。當我們想要建立”輕量級”異常時，使用第一個構造方法即可；如果我們想將系統級異常封裝成一下，並希望在日誌中列印棧追蹤時，就使用第三個構造方法。

PS: 只有在高併發系統中做上述優化才會有明顯效果。如果拋異常不頻繁的話也不會有明顯效果，因為即便是慢50倍，實際也是納秒級的區別，對一個請求處理來說微不足道。