9. 예외(Exception) 와 동시성(멀티스레드)

# 예외는 진짜 예외상황에서 사용하라.

정상적인 서비스 흐름에 예외를 사용하지 마라.

try-catch 문은 JVM의 최적화를 막아버리고 흐름 제어에 쓰인 예외 때문에 실제 버그가 숨겨져서 디버깅이 어려워진다.

 

이는 사용자(클라이언트)의 입장에서 생각하면 쉽다. 아래와 같은 코드를 생각해보자.

for(Iterator<Foo> i = collection.iterator(); i.hasNext();){
    Foo foo = i.next();
}

Iterator 인터페이스의 next(), hasNext() 메서드가 없다면 아래와 같이 사용해야 할 것이다. 이는 좋지 않다.

try{
    Iterator<Foo> i = collection.iterator();
    while(true)
        Foo foo = i.next();
        ...
    
} catch (NoSuchElementException e){}

원소가 없는건 정상적인 로직 흐름이다. 오류나 예외상황이 아니다.

예외가 발생했을 때는 정말 예외 상황이 일어났을 때이다. 사용자(클라이언트)에게 혼동을 주지 마라.

 

📌 상태검사 메서드(.hasNext()처럼 값을 바로 반환하는 메서드)와 상태 의존메서드(.next와 같이 true, false 체크 용도)

상태 의존메서드가 있는게 사용하기 훨씬 편하다.

하지만 외부 동기화 없이 여러 스레드가 동시에 접근할 수 있거나, 사이드 이펙트의 여지가 있다면 상태 의존메서드 없이 값을 바로 전달하거나 Optional등을 사용하는게 좋다. 그 잠깐동안 객체의 상태가 변할 수 있기 때문이다.

 

 

# 복구할 수 있다면 check 예외를, 아니라면 런타임 예외를 발생사용해라.

해당 메서드를 사용(호출)하는 쪽에서 복구를 해야한다면 checked 예외를 사용하라.

그게 아니라면 Runtime 예외를 발생시켜 오류임을 빨리 알려라. 예외를 감싸 예외 내용을 계층에 맞게 추상화하는 것도 좋다. DB 에서 SQL 에러가 난걸, 비즈니스 서비스에서 그대로 전달하는 거 보다 '서비스 동작 오류'로 추상화 시키자.

 

2021.07.07 - [🌱Backend/Java] - #7 Exception (예외처리)

#7 Exception (예외처리)

 

 

# 필요없는 검사 예외는 사용은 피하라.

꼭 예외를 사용하지 않아도 되는 메서드가 있다. 가능하면 Optional이나 검사 메서드(true, false)를 반환하게 만들자.

try{ // 기존 코드
    obj.action(args);

} catch(TheCheckedException e) {
    ...예외상황에 대처한다.
}

if(obj.actionPermitted(args)){ // 예외를 사용하지 않은 코드
    obj.action(args);
}else{
    ...예외상황에 대처한다.
}

* 단 검사메서드는 멀티스레드 환경이나 side-effect가 있다면 사용하지말고, 바로 값이나 Optional을 반환하자.

어떤 메서드가 check 예외를 던지는 것은, 이를 호출하는 입장에서 catch 블럭을 만들어 예외를 처리해야하는 부담이 생긴다. 또한 Java8 부터 사용하는 스트림에서는 예외 던지는 메서드를 사용하기 어렵다.

 

 

# 표준 예외를 사용하라.

재사용하기 쉽고, 가독성이 좋으며, 클래스를 안만들어도 되서 성능도 좋아진다.

IllegalArgumentException	허용하지 않는 값이 인수로 전달 됬을 때
IllegalStateException	객체가 메서드를 수행하기 적절하지 않을 때 (인수값이 무엇이든 어차피 실패)
NullPointerException	null을 허용하지 않는 메서드에 null을 건넸을 때
IndexOutOfBoundsException	인덱스가 범위를 넘었을 때
ConcurrentModificationException	허용하지 않는 동시 수정이 발견됬을 때
UnsupportedOperationException	호출한 메서드를 지원하지 않을때

다만 상위 예외(Exception, RuntimeException, Throwable, Error)는 재사용하지말자. 이들은 추상 클래스처럼 다른 예외들을 포함하는 상위 클래스이므로, 안정적으로 테스트할 수 없다. 만약 적절한 표준 예외가 없다면 상속받아 새롭게 만들자.

 

참고로 IllegalArgumentException 과 IllegalStateException이 헷갈릴 수 있는데, 인수 값이 무엇이든 어차피 실패했을 거라면 State를 사용하면 된다. 아니라면 Argument.

 

 

# 추상화 수준에 맞는 예외를 던져라.

비즈니스 서비스단에서 low-level의 메모리 예외가 나온다면 매우 당황스럽고, 처리할 방법도 없다.

저수준의 예외를 잡아서 새로운 예외로 추상화 시켜라. 디버깅에 도움이 된다면 예외 chain을 만드는게 좋다.

try{
    
} catch(LowerLevelException e){
    throw new HigherLevelException();
}

try{
    
} catch(LowerLevelException e){
    throw new HigherLevelException(e); // 이렇게 감싸는 것도 좋은방법. 예외의 근본 원인을 찾을 수 있다.
}

class HigherLevelException extends Exception {
    HigherLevelException(Throwable throwable){
        super(throwable);
    }
}

 

 

# 메서드가 던지는 예외는 모두 문서화해라.

메서드가 던질 가능성이 있는 예외는 모두 문서화하는게 좋다. 추상 메서드던, 런타임 메서드던 마찬가지이다.

@throws 또는 @Exception 태그를 활용하자. 참고로 이 두개의 기능은 같다.

public class Sample {

    /**
     * 파일 쓰기
     *
     * @throws FileNotFoundException 지정된 파일을 찾을 수 없습니다
     */
    public void writeToFile() throws FileNotFoundException {
    }

    /**
     * 파일 읽기
     *
     * @throws java.io.IOException         입출력 관련
     * @throws java.lang.SecurityException 보안 관련
     */
    public void readFromFile() throws IOException, java.lang.SecurityException {
    }
}

사용자 입장에서 이렇게 확인할 수 있다.

예외 상세메시지에 실패 관련 정보를 담으면 더 좋다.

// java9에서는 IndexOutOfBounds는 index를 받도록 추가되었다. 아쉽게도 lower, upper는 없음.
public IndexOutOfBoundsException(int lowerBound, int upperBound, int index) {
    super(String.format("최소값: %d, 최댓값: %d, 인덱스: %d", lowerBound, upperBound, index))
    
    this.lowerBound = lowerBound;
    this.uppperBound = upperBound;
    this.index = index;
}

* 단 예외에 보안과 관련된 정보(계정등)는 주의해서 다뤄야한다. 스택 추적 정보는 많은 사람이 볼 수 있기 때문이다.

 

 

# 가능하면 실패 원자적으로 만들어라.

예외가 발생했다면, 발생하기 전 상황을 유지하도록 만들어라.

일단 수정하고 문제가 있다면 예외를 발생시키는 것 보다 먼저 검사를 하고 수정하는게 좋다.

public Object pop() {
    if(size == 0) //메서드를 사용하기전 매개변수의 유효성을 검사하여 실패할 경우,상태 변경을 막는다!
        throw new EmptyStackException();
    
    Object result = elements[--size];
    elements[size] = null;
    return result;
}

이게 힘들다면 객체의 임시 복사본에서 작업을 수행한 다음, 성공했을 때 실제 객체와 교체하는 방법도 있다.

물론 이렇게 하지않고 따로 복구 코드를 작성하여 작업하기 전 상태로 돌리는 방법도 있지만, 좋은 방법은 아니다.

 

 

# 예외를 무시하지 마라.

뻔한 이야기 같지만, 종종 일어나는 일이다.

// catch 블록을 비워두면 예외가 무시된다. 아주 의심스러운 코드다!
try {
    ...
} catch (SomeException e) {
    //아무 일도 하지 않음.
}

이런 코드는 실제 예외가 발생했을 때, 이를 숨겨버려 디버깅을 매우 어렵게 만든다. 심한 경우 오류를 처리하지 않고 포함한 채로 앱이 동작하다가 문제의 원인을 전혀 모르는 상태로 갑자기 앱이 죽어버릴 수 있다.

 

정말 특수한 경우라서 예외가 필요없다면, 그 이유를 주석으로 남기고 예외 변수의 이름을 ignored 등으로 명시적으로 받아 나타내자. 또한 로그를 활용해 최소한의 디버깅 정보를 남기자.

 

 

# 공유중인 데이터는 동기화가 필수이다. (불변 데이터인 경우는 필요없음)

운영체제를 배웠다면 알겠지만, 여러 스레드가 동시에 값을 읽고 수정하는건 매우 위험한 행위이다.

심지어 동기화에서 발생한 버그는 디버깅 난이도가 높은편이다. 간헐적으로 발생하거나, 특정 타이밍에만 발생하고 VM의 최적화에 따라 다르게 동작하기도 하기 때문이다.

2021.07.28 - [👀기본 지식/CS 기본지식] - Java에서의 임계영역과 데드락 해결 (sync, 모니터)

2021.07.27 - [👀기본 지식/Java 기본지식] - 쓰레드 동기화 (sync, volatile, AtomicClass)

쓰레드 동기화 (sync, volatile, AtomicClass)

 

 

# 과도한 동기화는 피하라

동기화는 스레드를 블러킹하여 성능을 심하게 떨어뜨리고, 교착상태에 빠트린다.

꼭 필요한 곳에만 사용하자. synchronzied는 메서드단위가 아닌, { ~ } 블럭 단위로도 사용할 수 있다.

 

과도한 동기화는 병렬로 실행할 기회를 잃고, 모든 코어가 메모리를 일관되게 보기 위한 지연시간(블로킹)이 진짜 비용이다. 또한 JVM의 코드 최적화를 제한하는 것도 고려해야 한다.

 

따라서 가변 클래스를 작성할 때는 두 가지 선택을 할 수 있다.

첫 번째는 동기화를 하지 않고, 그 클래스를 사용해야 하는 클래스가 외부에서 동기화하는 것이다.

두 번째는 동기화를 내부에서 수행해 thread-safe 한 클래스로 만드는 것이다. 다만 클라이언트가 외부에서 객체 전체에 락을 거는 것보다 동시성을 개선할 수 있을 때 선택해야 한다. 예로는 java.util.concurrent 패키지가 있다.

 

java.util.Random도 마찬가지다. 동기화하지 않는 버전인 ThreadLocalRandom으로 대체되었다.

선택하기 어렵다면 동기화하지 말고, 대신 문서에 “스레드 안전하지 않다” 고 명시하자.

 

 

# 스레드를 직접 만들지말고 실행자, 테스크, 스트림을 이용하라.

스레드를 직접 다룰 수 있지만 concurrent 패키지를 이용하면 간단하게 코드를 작성할 수 있다.

이는 사용성 뿐만아니라 작업 단위와 실행 매커니즘을 분리하는 효과도 있다. 

java.util.concurrent 패키지 안에는 실행자 프레임워크(Executor Framework)가 있다.

// 큐를 생성한다.
ExecutorService exec = Executors.newSingleThreadExecutor();

// 태스크 실행
exec.execute(runnable);

// 실행자 종료
exec.shutdown();

https://madplay.github.io/post/prefer-executors-tasks-and-streams-to-threads

 

 

# 스레드 안전성 수준을 문서화해라.

반환 타입만으로 정확히 알 수없다면, (팩토리 메서드) 아래 처럼 자신이 반환하는 객체에 대한 스레드 안정성을 문서화하는 것이 좋다. 단순히 synchronized 키워드가 붙었다고해서, 모든 상황에서 안전하다는 보장은 할 수 없기 때문이다.

 

Collections.synchronziedMap 의 API 문서에는 아래와 같이 명시되어 있다.

/**
 * It is imperative that the user manually synchronize on the returned
 * map when iterating over any of its collection views
 * 반환된 맵의 콜렉션 뷰를 순회할 때 반드시 그 맵으로 수동 동기화하라
 * 
 *  Map m = Collections.synchronizedMap(new HashMap());
 *      ...
 *  Set s = m.keySet();  // Needn't be in synchronized block
 *      ...
 *  synchronized (m) {  // Synchronizing on m, not s!
 *      Iterator i = s.iterator(); // Must be in synchronized block
 *      while (i.hasNext())
 *          foo(i.next());
 *  }
 */

• 불변(immutable)
  • ➡ 해당 클래스의 인스턴스는 마치 상수와도 같아서 외부 동기화도 필요 없습니다.
  • ➡ 예를 들면 String, Long, BigInteger
• 무조건적인 스레드 안전(unconditionally thread-safe)
  • ➡ 해당 클래스의 인스턴스는 수정될 수 있지만 내부에서도 충실히 동기화하여 별도의 외부 동기화없이 동시에 사용해도 안전합니다.
  • ➡ 예를 들면 AtomicLong, ConcurrentHashMap
• 조건부 스레드 안전(conditionally thread-safe)
  • ➡ 무조건적인 스레드 안전성과 같지만 일부 메서드는 동시에 사용하려면 외부 동기화가 필요합니다.
  • ➡ Collections.synchronized 래퍼 메서드가 반환한 컬렉션
• 스레드 안전하지 않음(not thread-safe)
  • ➡ 해당 클래스의 인스턴스는 수정될 수 있으며 동시에 사용하려면 각각의 메서드 호출을 클라이언트가 선택한 외부 동기화 로직으로 감싸야 한다.
  • ➡ 예를 들면 ArrayList, HashMap
• 스레드 적대적(thread-hostile)
  • ➡ 외부 동기화로 감싸더라도 멀티스레드 환경에서 안전하지 않습니다.
  • ➡ 이러한 클래스는 동시성을 고려하지 않고 만들다보면 우연히 만들어집니다.

 

 

# 지연 초기화는 신중히 사용하라.

반대로 말하면 꼭 필요하기 전까지는 사용하지 말라는 거다. 지연 초기화는 양날의 검이다.

초기화에 드는 비용, 초기화된 필드의 호출 빈도수에 따라 지연 초기화가 오히려 성능을 악화시킬 수 있다. 크게 필요한 상황이 아니라면, 일반적인 초기화가 훨씬 낫다.

// 일반적인 인스턴스 필드 초기화 방법
private final FieldType field = computeFieldValue();

 

 

성능 때문에 정적 필드를 초기화해야한다면, 내부 Holder 클래스나 Double-check 관용구를 사용하자.

2-3 Singleton (싱글톤 패턴)

public MyClass{

    private static FieldType getField() { 
        return FieldHolder.field;
    }

    private static class FieldHolder {
        static final FieldType field = computeFieldValue();
    }
}

 

 

# 프로그램의 동작을 스레드 스케쥴러에 기대지 말라.

스케쥴러 정책은 운영체제마다 다를 수 있다. Thread.yield(다른 스레드에게 실행을 양보하는 메서드) 처럼 스레드 우선순위를 바꾸는건 스케쥴러에 제공하는 '힌트' 일 뿐이지, 반드시 그렇게 동작할거라는 보장은 없다. 자바의 스레드 우선순위는 운영체제 이식성이 나쁜편이다.

 

또한 스레드는 절대로 busy-waiting 한 상태가 되면 안된다. 해당 스레드 때문에 앱 전체에서 다른 유용한 작업이 실행될 기회가 박탈됨을 인지하고 있자.

// Busy-waiting 코드. 지금 작동해도 되는지 여부를 계속해서 스레드가 스스로 검사함.
public class SlowCountDownLatch {
    private int count;

    public SlowCountDownLatch(int count) {
        if (count < 0)
            throw new IllegalArgumentException(count + " < 0");
        this.count = count;
    }

    public void await() {
        while (true) { // 진짜 이렇게 할건가?
            synchronized(this) {
                if (count == 0)
                    return;
            }
        }
    }

    public synchronized void countDown() {
        if (count != 0)
            count--;
    }
}