DEV ℧ Developer Diary

[EffectiveJava] item76 - 가능한 한 실패 원자적으로 만들라

작업 도중 예외가 발생해도 그 객체는 여전히 정상적으로 사용할 수 있는 상태라면 멋질것이다. 검사 예외를 던진 경우라면 호출자가 오류 상태를 복구할 수 있을 테니 특히 더 유용할 것이다.

일반화해 이야기하면, 호출된 메서드가 실패하더라도 해당 객체는 메서드 호출 전 상태를 유지해야 한다. 이러한 특성을 실패 원자적(failure-atomic)이라고 한다.

실패 원자적을 만드는 방법

1. 불변 객체로 설계

가장 간단한 방법은 불변객체로 설계하는 것이다. 불변객체는 태생적으로 실패 원자적이다.

메서드가 실패하면 새로운 객체가 만들어지지는 않을 수 있으나 기존 객체가 불안정한 상태에 빠지는 일은 결코 없다.

2. 매개변수 유효성 검사

가변 객체의 메서드를 실패 원자적으로 만드는 가장 흔한 방법은 작업 수행 전 매개변수의 유효성을 검사하는 것이다.

객체의 내부 상태를 변경하기 전에 잠재적 예외의 가능성 대부분을 걸러낼 수 있는 방법이다.

Stack.pop() 예시

public Object pop() {
    if (size == 0)
        throw new EmptyStackException();
    Object result = elements[--size];
    elements[size] = null; /* 다 쓴 객체 참조 */
    return result;
}

이 메서드는 처음의 if문에서 size의 값을 확인하여 0이면 예외를 던진다.

사실 이부분을 제거하더라도 스택이 비었다면 예외를 던질 테지만 size의 값이 음수가 되어 다음번 호출도 실패하게 만들며, 이때는 IndexOutOfBoundsException 예외가 발생할 것이다.
IndexOutOfBoundsException는 추상화 수준이 상황에 어울리지 않다고 볼 수 있다.

이와 비슷한 취지로 실패할 가능성이 있는 모든 코드를, 객체의 상태를 바꾸는 코드보다 앞서 배치하는 방법도 있다.

3. 객체의 임시 복사본을 통한 작업

실패 원자성을 얻는 방법으로는 객체의 임시 복사본에서 작업을 수행한 다음, 작업이 성공적으로 완료되면 원래 객체와 교체하는 방법도 있다.

데이터를 임시 자료구조에 저장해 작업하느게 더 빠를 때 적용하기 좋은 방식이다.

예를 들면 어떤 정렬 메서드에서는 정렬을 수행하기 전에 입력 리스트의 원소들을 배열로 옮겨 담는다.
배열을 이용해 정렬 알고리즘의 반복문에서 원소들을 훨씬 바르게 접근할 수 있을 뿐더러, 혹여나 정렬에 실패하더라도 입력 리스트는 변하지 않는 효과를 얻게 된다.

4. 복구 코드 작성

작업 도중 발생하는 실패를 가로채는 복구 코드를 작성하여 작업 전 상태로 되돌리는 방법이다.

주로 디스크 기반의 내구성(durability)을 보장해야 하는 자료구조에 쓰이는데, 자주 쓰이는 방법은 아니다.

실패 원자성이 불가능한 상태

실패 원자성은 일반적으로 권장되는 덕목이지만 항상 달성할 수 있는 것은 아니다.

예를 들어 두 스레드가 동기화 없이 같은 객체를 동시에 수정한다면 그 객체의 일관성이 깨지면서 ConcurrentModificationException 예외를 발생할 경우 그 객체가 여전히 쓸 수 있는 상태라고 가정해서는 안된다.

실패 원자적으로 만들 수 있더라도 항상 그리 해야 하는 것도 아니다. 실패 원자성을 달성하기 위한 비용이나 복잡도가 아주 큰 연산도 있기 때문이다.

메서드 명세에 기술한 예외

메서드 명시에 기술한 예외라면 설혹 예외가 발생하더라도 객체의 상태는 메서드 호출 전과 똑같이 유지돼야 한다는 것이 기본 규칙이다.

이 규칙을 지키지 못한다면 실패 시의 객체 상태를 API 설명에 명시해야 한다.