Java의 예외 생성 비용은 비싸다

서론

보통 프로젝트를 진행할 때, 아래와 같은 장점 때문에 자바에서 제공하는 예외 클래스 외에 개발자가 직접 Custom Exception 클래스를 정의하여 자주 사용합니다. 

• 에러 처리의 일관성과 가독성 유지: 개발자가 직접 예의 클래스를 정의하므로, 에러 메시지를 보다 명확하게 정의할 수 있고, 개발자가 직접 일관성 있게 에러처리를 정의할 수 있다.
• 로깅 및 디버깅에 용이: 개발자가 예외 클래스에 디버깅 정보를 추가하여 예외가 발생했을 때 디버깅을 용이하게 할 수 있다.
• 예외 처리의 유연성: 예외 클래스를 상속하여 사용하는 등 다양한 예외 처리 방식을 적용할 수 있다.

하지만 이러한 장점 외에도, 자바에서는 Exception의 처리 비용이 매우 비싸다는 문제가 있습니다. 이번 게시글에서는 JVM에서 Exception이 처리되는 순서와 Exception의 생성 비용이 비싼 이유, 그리고 비용을 줄이는 방법에 대해 정리해 보겠습니다.

목차

• JVM의 Exception 처리 순서
• Exception 비용이 생기는 원인
• 비용을 줄이는 방법

 

JVM의 Exception 처리 순서

먼저 JVM에서 Exception을 수행하는 과정은 아래와 같습니다.

1. 예외 발생: 예외가 발생하면 JVM은 예외 객체를 생성하고, 예외를 발생시킨 메서드의 호출 스택을 추적한다.
2. 예외 객체 전파: JVM은 해당 예외를 발생시킨 메서드에서 예외 처리 코드를 찾고, 예외 처리 코드가 없는 경우 예외 객체를 호출 스택의 상위 메서드로 전파시킨다.
3. 예외 처리: 예외 객체가 상위 메서드로 전파되면, 해당 예외를 처리할 수 있는 catch 블록을 찾고, 없다면 예외는 다시 상위 메서드로 전파된다.
4. 예외 처리 실패: 예외 객체가 최상위 메서드까지 전파되어도, 예외를 처리할 수 있는 catch블록이 없는 경우 JVM은 예외를 처리하지 못한 것으로 판단하여 해당 예외를 처리할 수 있는 Default Exception Handler를 사용하여 예외를 처리한다.
5. Default Exception Handler 실행: Default Exception Handler는 예외 객체에 대한 정보를 출력하고, 해당 예외를 처리하거나 예외 객체에 대한 스냅샷 정보를 수집하여 디버깅을 위한 정보로 제공한다.

예외가 발생한 메서드에서 바로 처리가 된다면 가장 좋지만, 바로 처리되지 못하면 JVM은 해당 예외를 처리할 수 있는 메서드를 찾을 때 까지 계속해서 상위 메서드로 거슬러 올라가면서 메모리의 호출 스택(call stack)을 탐색하게 됩니다.
 

비용이 생기는 원인

먼저 호출 스택을 탐색하는 과정 자체도 비용이지만, fillInStackTrace() 메서드가 호출 스택을 순회하며 클래스명, 메서드명, 코드 줄 번호 등의 정보를 모아 stacktrace로 만드는 과정 또한 비용 증가의 원인입니다.

fillInStackTrace()에 의해 모아진 정보들

fillInStackTrace()는 Throwable 클래스에 정의된 구현 메서드로 생성자에서 호출되도록 되어있며, 모든 Exception은 Throwable을 상속받도록 되어있기 때문에 fillInStackTrace() 메서드를 가지고 있습니다.

일반적으로 StackTrace를 생성하는 시간은 몇 밀리초에서 몇 초까지 다양합니다. 하지만 이는 예외가 발생한 환경, StackTrace의 깊이, StackFrame의 메서드 호출 수, JVM의 버전 및 설정 등에 다르기 때문에 시간을 정의하기는 어렵습니다. 

• https://sudonull.com/post/72142-Everything-you-wanted-to-know-about-stack-traces-and-hip-dumps-Part-1-JUG-Ru-Group-Blog
• https://shipilev.net/blog/2014/exceptional-performance/
• https://segmentfault.com/a/1190000040373647/en

하지만 위의 몇몇 블로그를 보면, Stack Trace가 깊을수록 오랜 시간이 걸린다는 것은 분명합니다.
 

비용을 줄이는 방법

1. fillInStackTrace() 메서드 재정의
2. 예외 캐싱

1. fillInStackStrace 재정의

보통 NullPointException이나 OutOfMemory와 같이 자바에서 기본적으로 제공하는 예외를 제외한, 우리가 만든 Custom Exception은 에러의 추적 보다는 유효하지 않는 값일 때 하위 비즈니스 로직을 수행하지 못하도록 하기 위한 용도로 주로 사용됩니다. 따라서 보통StackTrace가 필요하지 않습니다. 

@Override 
public synchronized Throwable fillInStackTrace() {
   return this;
}

때문에 단순히 Try-Catch로 이후의 Flow를 제어하거나, Spring 환경에서 @ControllerAdvice로 예외를 처리하는 경우에는 불필요한 성능 저하를 막기 위해 아무 trace도 저장하지 않도록 직접 위 코드처럼 fillInStackTrace()를 오버라이딩하여 처리할 수 있습니다.

예시 코드

public class DuplicateLoginException extends RuntimeException {
    public DuplicateLoginException(String message) {
        super(message);
    }

    @Override
    public synchronized Throwable fillInStackTrace() {
        return this;
    }
}

 

fillInStackTrace() 재정의 전 에러 예시

kancho.realestate.comparingprices.exception.DuplicateLoginException: 이미 로그인한 상태입니다.
    at kancho.realestate.comparingprices.controller.UserController.validateDuplicateLogin(UserController.java:67)
    at kancho.realestate.comparingprices.controller.UserController.login(UserController.java:44)
    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.base/java.lang.reflect.Method.invoke(Method.java:566)
    at org.springframework.web.method.support.InvocableHandlerMethod.doInvoke(InvocableHandlerMethod.java:205)
    at org.springframework.web.method.support.InvocableHandlerMethod.invokeForRequest(InvocableHandlerMethod.java:150)
    at org.springframework.web.servlet.mvc.method.annotation.ServletInvocableHandlerMethod.invokeAndHandle(ServletInvocableHandlerMethod.java:117)
    at org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.invokeHandlerMethod(RequestMappingHandlerAdapter.java:895)
    at org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.handleInternal(RequestMappingHandlerAdapter.java:808)
    at org.springframework.web.servlet.mvc.method.AbstractHandlerMethodAdapter.handle(AbstractHandlerMethodAdapter.java:87)
    at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:1067)
    at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:963)
    at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:1006)
    at org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:909)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:681)
    at org.springframework.web.servlet.FrameworkServlet.service(FrameworkServlet.java:883)
    at org.springframework.test.web.servlet.TestDispatcherServlet.service(TestDispatcherServlet.java:72)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:764)
    at org.springframework.mock.web.MockFilterChain$ServletFilterProxy.doFilter(MockFilterChain.java:167)
    at org.springframework.mock.web.MockFilterChain.doFilter(MockFilterChain.java:134)
    at org.springframework.web.filter.RequestContextFilter.doFilterInternal(RequestContextFilter.java:100)
    at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:119)
    at org.springframework.mock.web.MockFilterChain.doFilter(MockFilterChain.java:134)
    at org.springframework.web.filter.FormContentFilter.doFilterInternal(FormContentFilter.java:93)
    at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:119)
    at org.springframework.mock.web.MockFilterChain.doFilter(MockFilterChain.java:134)
    at 

... 생략

 

fillInStackTrace() 재정의 후 에러 예시

kancho.realestate.comparingprices.exception.DuplicateLoginException: 이미 로그인한 상태입니다.

2. 예외 캐싱하기

static final로 선언하여 이용해 예외를 미리 캐싱하여 사용할 수 있습니다. 일종의 상수 값 형태로 예외를 캐싱해 두고 쓰는 것이 매번 같은 종류의 예외로 new로 생성하는 방법보다 효율적입니다.

public class CustomException extends RuntimeException {
    public static final CustomException INVALID_NICKNAME = new CustomException(ResponseType.INVALID_NICKNAME);
    public static final CustomException INVALID_PARAMETER = new CustomException(ResponseType.INVALID_PARAMETER);
    public static final CustomException INVALID_TOKEN = new CustomException(ResponseType.INVALID_TOKEN);
    //생략
}

위와 같이 Exception 클래스에 예외 상황에 대한 적당한 응답 메시지나 코드를 담도록 한 뒤, 아래처럼 예외 발생 상황에서 new 키워드 없이 throw를 수행하도록 합니다.

if (StringUtils.isBlank(parameter)) {
	throw WebtoonCoreException.INVALID_PARAMETER;
}

 
 

참고

• https://shipilev.net/blog/2014/exceptional-performance/
• https://thswave.github.io/java/exception/2015/06/28/exceptions-are-bad.html
• https://jerry92k.tistory.com/42