Thread에서 발생하는 문제들

자바 트러블슈팅: scouter를 활용한 시스템 장애 진단 및 해결 노하우를 챕터 8을 요약한 내용입니다.

 

---

Thread에서 발생하는 문제들을 알아야 하는 이유

대부분의 프로그래밍 언어는 하나의 프로세스로 수행되고, 1개 이상의 쓰레드를 활용하여 처리한다. 대부분 장애는 스레드에서 수행되는 프로그램에서 발생한다.

---

Thread에서 발생하는 문제들

자바 관련 서적 중(High0Performance Java Platform Computing)이라는 책의 3장에는 스레드를 처리함에 있어서 대표적인 문제가 다음과 같이 분류되어 있다.

• 레이스 컨디션(race condition)
• 데드락(deadlock)
• 스타베이션(starvation)
• 라이브 록(live lock)
• 다른 형태의 예측 불가능한 오류(nondeterminism)

레이스 컨디션

멀티 스레드 환경에서 공유 데이터에 대해 아무런 락 처리를 하지 않을 경우, 동시에 스레드가 처리하러 들어왔을 때 무한 대기하거나 무한 루프에 빠지는 것을 말한다. 그러므로 멀티 스레드 환경이면 락을 걸어주자.

 

데드록

두 개 이상의 스레드에서 이 락이 서로 풀리기만을 기다리는 상황이 발생할 수 있는데, 이러한 상황을 데드록이라고 한다.

• 스레드 1이 DataA에 록을 건 상태에서 DataB에 접근하려고 한다.
• 스레드 2가 DataB에 록을 건 상태에서 DataA에 접근하려고 한다.

이 처럼 타이밍이 딱 맞아 떨어져서 두 스레드가 동시에 요청되어 서로 물고 물리는 상황이 되고, 둘 다 대기하고 있는 상태를 데드록이라고 한다.

public class Deadlock {
    static class Friend {
        private final String name;
        public Friend(String name) {
            this.name = name;
        }
        public String getName() {
            return this.name;
        }
        public synchronized void bow(Friend bower) {
            System.out.format("%s: %s"
                + "  has bowed to me!%n", 
                this.name, bower.getName());
            bower.bowBack(this);
        }
        public synchronized void bowBack(Friend bower) {
            System.out.format("%s: %s"
                + " has bowed back to me!%n",
                this.name, bower.getName());
        }
    }

    public static void main(String[] args) {
        final Friend alphonse =
            new Friend("Alphonse");
        final Friend gaston =
            new Friend("Gaston");
        new Thread(new Runnable() {
            public void run() { alphonse.bow(gaston); }
        }).start();
        new Thread(new Runnable() {
            public void run() { gaston.bow(alphonse); }
        }).start();
    }
}

// result
// Alphonse: Gaston has bowed to me!
// Gaston: Alphonse has bowed to me!

스타베이션

스타베이션은 멈추어 있는 스레드가 이론적으로 수행은 할 수 있지만 CPU로부터 일할 기회를 받지 못하는 경우 때문에 발생한다. 

라이브 록

하나의 스레드에서 다른 스레드로 응답을 주는 경우가 있다. 그런데 응답을 받은 스레드에서 요청했던 스레드로 다시 요청을 하는 작업이 계속 반복될 수 있는데, 이것을 라이브 록이라고 한다. 라이브 록과 데드록의 차이는 데드록의 경우 CPU를 점유하지 않고 멈추어버리지만, 라이브 록은 멈추지 않고 지속해서 수행하므로 CPU까지 점유할 확률이 높다. 그렇게 되면 CPU 코어 하나를 모두 점유해 버릴 수 있으니 CPU 사용량도 같이 모니터링하는 것을 권장한다.

다른 형태의 예측 불가능한 오류

앞의 레이스 컨디션은 예측 불가능한 오류의 일종이다. 그런데 레이스 컨디션 말고도 예측 불가능한 오류가 존재한다. 예를 들면, 별도로 수행되는 멀티 스레드 프로그램이 있는데, 그 결과는 항상 같다고 생각했지만, 경우에 따라서 그 결과가 달라지는 경우가 여기에 속한다. 보통 트랜잭션을 처리하는 부분에서 이러한 상황이 발생한다.

---

록 경합을 피하는 10 + 1가지 방법

코드가 아닌 데이터를 보호하라(Protext data, not code)

스레드에 안전한 코드를 위해서 전체 함수 호출을 큰 록으로 감싸는 것이다. 자바에서는 메서드를 synchronized로 선언하는 것이 그 예다. 하지만 동시에 여러 스레드에서 접근하는 것을 막을 대상은 데이터지 코드가 아니다.

따라서, 데이터만 synchronized 블록으로 감싼다면 중요한 코드를 잠그는 데 수행하는 시간을 줄일 수 있다.

록 사용 부분에서는 비싼 계산을 하지 말아라

재정렬 작업을 짧게 하고 임시 변수를 사용하는 등의 작업으로 락서 소요하는 시간을 줄일 수 있다. 특히 I/O와 관련된 작업이라면 효과가 더 크다.

록을 분리해라

배열 전체가 동일한 록으로 보호 받지 않고, 배열 각각의 요소에 따로 락을 걸 수 있다면 배열 요소들이 서로 다른 록을 갖도록 분산하고, 스레드 간의 동일한 록을 얻기 위해서 결쟁하지 않도록 만드는 것이 좋다. 조금 더 일반적인 조언을 덧붙이자면, 서로 다른 데이터에는 서로 다른 락을 사용하라는 것이다.

내부적인 락이나 atomic 작업을 사용하라

대부분의 병렬 프로그램 시스템은 단순한 작업을 수행할 수 있도록 atomic 연산을 제공한다.

동기화된 데이터 구조를 사용하라

만약 atomic 연산을 직접 사용할 수 없다면, 내부적으로 atomic을 사용하는 데이터 구조를 사용할 수 있다. lock-free 메시지 큐가 그 예다.

가능하다면 읽기-쓰기 락 디자인 패턴을 사용하라

많은 읽기 작업만 수행하는 사용자들은 동시에 처리할 수 있고, 쓰기 위한 사용자는 락을 걸어서 처리하는 읽기와 쓰기 락(reader-writer lock)을 사용할 수 있다 .

가능하다면 읽기 전용 데이터를 사용하라

자바를 포함한 몇몇 동시 처리 프로그래밍 시스템은 락을 걸지 않고도 모든 스레드에서 접근할 수 있는 읽기 전용 데이터를 만들 수 있다.(단, 그 데이터가 전혀 변경되지 않는다는 조건을 만족해야만 한다)

객체 풀링을 피해라

이전에는 객체를 생성하는 비용이 매우 비싸서 여러 스레드가 재사용하기 위해 생성된 객체를 풀(pool)에 저장해두었다. 하지만 동시에 여러 스레드가 풀에 접근할 경우에는 데이터 보호 때문에 다중 스레드에서는 문제가 된다. 그러니 객체를 생성하여 풀에다 저장하는 일은 피하는 편이 좋다.

지역 변수를 사용하거나 스레드 로컬 저장소를 사용하라

많은 경우에 각각의 스레드의 로컬에 있는 공유 변수는 다른 것으로 치환할 수 있다. 이렇게 했을 때 데이터를 처리하는 비용이 감소되는 간단한 경우를 생각해 보자. 먼저, 배열에 있는 가장 큰 수를 찾을 때를 예로 들어보자. 많은 스레드에서 값이 증가될 때마다 최댓값을 따로 저장해 놓는다면, 매번 최댓값을 찾기 위해서 데이터를 검색하는 비용을 줄일 수 있을 것이다. 아니면, 각 스레드 저장소에 결괏값을 따로 갖고 있다가, 필요할 때에만 마지막에 그 결과를 취합할 수도 있다. (동시 접근이 적은 경우에 적합)

핫스폿을 피하라(Avoid hotsopts)

핫스폿이란 리스트의 요소 개수가 변경될 때마다 크기를 저장하는 변수를 수정하기 위해 수행되는 메서드에 락을 거는 것을 말한다. 이 경우에 이러한 문제를 해결하는 가장 쉬운 방법은 목록의 크기를 저장하지 않는 것이다. 하지만 리스트의 크기를 확인하는 시간은 데이터의 개수가 많을수록 증가할 것이다. 소프트웨어 개발은 가장 적합한 트레이드오프를 찾는 작업이다.

 

트랜잭션을 제공하는 메모리 시스템을 사용하라

트랜잭션을 처리하는 메모리는 락을 처리하기 위해 복잡한 부분을 없애 주기 때문에 매우 정제된 락의 모든 장점을 여러분에게 제공할 것이다. 하지만 불행하게도 실제 운영 상황에서 적용할 수 있는 트랜잭션 처리가 가능한 메모리를 보지 못했다.

---

끝나지 않는 루프

CPU를 지속해서 점유할 확률이 높고, 최악의 경우 객체의 크기가 지속해서 커져서 메모리까지 점유하게 된다.

---

스레드 개수 문제에 대한 권장안

최대 스레드 수 설정 이유

• 최대 풀 갯수를 넉넉하게 할 수는 있지만 그만큼 애플리케이션에서 가용한 메모리는 줄어든다.

 

최대 스레드 수

• 상위 80% 요청을 대상으로 진행
• 동시 사용자 수 / 평균 응답속도 x 1.25 or 1000개

 

참고로 Tomcat과 같은 WAS의 경우 초기 스레드 개수와 최대 스레드 개수를 정한다고 하더라도, 처음부터 그 개수만큼 스레드 풀을 생성하지는 않는다. 다시 말해서, 스레드가 부족할 경우 스레드를 증가하는 방식을 사용한다.

 

 

---

참고

• https://docs.oracle.com/javase/tutorial/essential/concurrency/deadlock.html
• https://www.thinkingparallel.com/2007/07/31/10-ways-to-reduce-lock-contention-in-threaded-programs/