출처 : http://www.ibm.com/developerworks/kr/library/j-concurrencybugpatterns/index.html
Double Checked Locking, Wait Not In Loop, Unconditional Wait, Mismatched Wait and Notify, Two Locks Held While Waiting 과 같은
동시성 패턴 관련 기본적인 선수 지식을 가지고 보는 것이 좋습니다.
멀티코어 시스템의 Java 동시성 버그 패턴
덜 알려진 여섯 가지 Java 동시성 버그 패턴
원문 게재일： 2010 년 12 월 21 일
번역 게재일： 2011 년 4 월 19 일
난이도： 초급
원문： 보기
PDF： A4 and Letter (73KB | 12 pages)
[목차]
멀티스레드 프로그래밍에 대한 경험이 부족한 프로그래머가 멀티코어 시스템용 소프트웨어에 적용하는 데는 두 가지 과제가 존재한다.
첫째, 동시성으로 인해 재생하고 진단하기가 매우 어려운 새로운 범주의 Java 프로그램 버그(예: 데이터 경쟁 및 교착 상태)가 생겨났다.
둘째, 많은 프로그래머가 코드에서 오류를 일으킬 수 있는 특정 멀티스레드 프로그래밍 이디엄의 미묘한 점을 인식하지 못한다.
동시성 프로그래밍을 하는 과정에서 버그가 생기지 않도록 하려면,
Java 프로그래머가 멀티스레드 코드에서 버그가 나타날 수 있는 중요한 시점을 인식하는 방법을 배워서 버그가 없는 소프트웨어를 작성해야 한다.
이 기사는 동시성 프로그래밍의 특성에 이해 수준이 높지 않거나 낮은 개발자를 대상으로 한다.
이중 확인 잠금(double-checked locking), 반복 대기(spin wait) 및 wait-not-in-loop와 같은 잘 알려진 동시성 버그 패턴에 초점을 맞추기 보다는 덜 알려졌지만
실제 Java 애플리케이션에서 자주 드러나는 여섯 가지 패턴을 소개한다. 사실상, 첫 번째 두 가지 사례는 일반적으로 사용되는 두 가지 웹 서버에서
실제로 발견된 버그이다.
첫 번째 동시성 버그는 널리 사용되는 오픈 소스 HTTP 서버인 Jetty에서 발견되었다.
이 버그는 Jetty 커뮤니티에서 실제로 확인한 버그이다. (버그에 대한 보고서는 참고자료를 참조한다.)
목록 1. 잠금을 유지하지 않은 상태에서의 휘발성 필드에 대한 비원자적 조작
// Jetty 7.1.0, // org.eclipse.jetty.io.nio, // SelectorManager.java, line 105 private volatile int _set; ...... public void register(SocketChannel channel, Object att) { int s=_set++; ...... } ...... public void addChange(Object point) { synchronized (_changes) { ...... } } |
목록 1 에는 여러 개의 오류가 결합되어 있다.
- 첫 번째,
_set는volatile로 선언되었다. 따라서 다중 스레드에서 이 필드를 액세스할 수 있다. - 그러나
_set++는 원자적이 아니므로 반드시 하나의 개별 조작으로 실행되는 것은 아니다.
그 보다는 세 개의 분리된 조작(읽기 - 수정 - 쓰기)으로 구성된 시퀀스가 단축된 것으로 볼 수 있다. - 결국,
_set++는 잠금을 통해 보호할 수 없다.register메소드는 다중 스레드에 의해 동시에 호출된다.
따라서 경쟁 조건이 발생하여_set값이 올바르지 않게 된다.
이러한 오류는 Jetty 코드에서 발생했던 것만큼 쉽게 독자의 코드에서도 나타날 수 있으므로 이러한 오류가 어떻게 발생했는지 자세히 살펴보도록 하자.
코드의 논리적 시퀀스를 통해 코드를 따라가다 보면 이러한 버그 패턴을 명확하게 파악할 수 있다. 다음과 같은 변수 i에 대한 조작 등은
i++
--i
i += 1
i -= 1
i *= 2
|
비원자적 조작이다(즉, read-modify-write). Java 언어의 volatile 키워드는 변수의 가시성만 보장하지 원자성은 보장하지 않는다.
따라서 이점을 진지하게 생각해 보아야 한다. 잠금으로 보호할 수 있는 휘발성 필드에 대한 비원자적 조작으로 인해 경쟁 조건이 발생할 수 있지만,
이러한 상황은 다수의 스레드에서 비원자적 조작을 동시에 액세스하는 경우에만 해당된다.
스레드로부터 안전한 프로그램에서는 하나의 쓰기 스레드만 변수를 수정할 수 있으며, 다른 스레드는 변수를 volatile로 선언하여 최신 값만을 읽을 수 있다.
따라서, 코드에 버그가 많은지 적은지는 다수의 스레드가 해당 조작에 어떻게 동시에 액세스할 수 있는지에 달렸다.
하나의 스레드에서 비원자적 조작을 호출하면, 시작 - 결합 관계나 외부 잠금으로 인해 코드 이디엄이 스레드로부터 안전하게 된다.
Java 코드의 volatile 키워드는 변수가 가시적이라는 점만 보장하지 원자성은 보장하지 않는다는 점을 기억해야 한다.
변수 조작이 비원자적이고 다수의 스레드에서 이 변수 조작을 액세스할 수 있는 경우에는 휘발성 동기화 기능에 의존해서는 안 된다.
그 대신java.util.concurrent 패키지의 동기화된 블록, 잠금 클래스 및 원자적 클래스를 사용해야 한다.
이러한 것들은 스레드 안전성 문제를 보장하기 위해 설계되었다.
Java 언어에서는 동기화된 블록을 사용하여 멀티스레드 시스템에서의 공유 자원 액세스를 보호하는 상호배제 잠금을 수행한다.
그러나 변경 가능 필드를 대상으로 동기화를 하는 경우에는 허점이 생기고 이로 인해 상호배제 규칙을 위반하게 될 수 있다.
이에 대한 해결책은 동기화된 블록을 언제나 private final로 선언하는 것이다. 그 이유를 확인하기 위해 이러한 문제점을 자세히 살펴보도록 하자.
동기화된 블록은 필드 자체보다는 동기화 필드에서 참조된 오브젝트에 의해 보호된다. 동기화 필드가 변경 가능하고 따라서 이 필드를
프로그램의 초기화 부분 이외의 어느 위치에 지정할 수 있는 경우, 다른 스레드는 다른 오브젝트를 대상으로 동기화할 수 있기 때문에
동기화 필드에 유용한 시맨틱이 있다고 할 수 없다.
목록 2에서 이러한 문제를 확인할 수 있다. 목록 2는 오픈 소스 웹 애플리케이션 서버인 Tomcat의 코드 스니펫이다.
목록 2. 오류가 있는 Tomcat
96: public void addInstanceListener(InstanceListener listener) { 97: 98: synchronized (listeners) { 99: InstanceListener results[] = 100: new InstanceListener[listeners.length + 1]; 101: for (int i = 0; i < listeners.length; i++) 102: results[i] = listeners[i]; 103: results[listeners.length] = listener; 104: listeners = results; 105: } 106: 107:} |
listeners는 배열 A를 참조하고, 스레드 T1이 먼저 배열 A에 대한 잠금을 획득한 다음, 배열 B를 작성 중이라고 가정하자.
그동안에 뒤이어 T2가 배열 A에 대한 잠금을 차단한다. T1이 배열 B에 listeners를 설정하는 것을 완료하고 이러한 차단을 종료하면,
T2는 배열 A를 잠그고 배열 B를 복사하기 시작한다. 그런 다음에는 뒤이어 T3가 배열 B를 잠근다.
스레드가 서로 다른 잠금을 획득했기 때문에 이제 T2와 T3는 배열 B를 동시에 복사하게 된다.
그림 1에는 이러한 시퀀스가 자세히 설명되어 있다.
그림 1. 변경 가능 필드에 대한 동기화로 인한 상호배제의 결여
이와 같은 설정으로 부터 바람직하지 않은 작동이 많이 발생할 수 있다.
적어도 새로운 listners 중 하나가ArrayIndexOutOfBoundsException을 잃거나 스레드 중 하나가 이것을 얻을 수 있는데,
이는 listeners가 이것을 참조하고 메소드의 어느 위치에서는 이것의 길이가 변경될 수 있기 때문이다.
동기화 필드를 언제나 private final로 선언하는 것이 우수 사례이다. 이렇게 하면 잠금 오브젝트가 변경되지 않으며 상호배제가 보장된다.
잠금은 java.util.concurrent.locks.Lock 인터페이스로 구현되며 이것을 이용하여 다수의 스레드가 공유 자원을 액세스하는 방법을 제어한다.
이러한 잠금에는 차단 구조가 필요하지 않기 때문에 잠금은 동기화 방법이나 동기화 명령문보다 더욱 유연하다.
그러나 차단을 하지 않으면 잠금은 결코 자동으로 릴리스되지 않기 때문에 이러한 유연성으로 인해 코딩 오류가 발생할 수 있다. Lock.lock() 호출에는 동일한 인스턴스를 대상으로 하는 unlock() 호출이 없기 때문에 잠금 오류가 발생할 수 있다.
throw를 사용하여 처리할 수 있는 예외와 같은 메소드 작동을 중요한 코드에서 간과하게 되면 java.util.concurrent 잠금 오류 버그가 발생하기 쉽다.
목록 3에서 이것을 확인할 수 있다. 여기서는 공유 자원을 액세스하는 과정에서 accessResource 메소드가InterruptedException을 throw로 처리한다.
결과적으로 unlock()은 호출되지 않는다.
목록 3. 잠금 오류의 구조
private final Lock lock = new ReentrantLock(); public void lockLeak() { lock.lock(); try { // access the shared resource accessResource(); lock.unlock(); } catch (Exception e) {} public void accessResource() throws InterruptedException {...} |
잠금이 릴리스되었는지 확인하려면 모든 lock 메소드를 try-finally 블록에 있어야 하는 unlock 메소드와 짝을 맞추어 본다.
이 과정은 목록 4에 표시되어 있다.
목록 4. unlock 호출을 언제나 try-finally 블록에 삽입
private final Lock lock = new ReentrantLock(); public void lockLeak() { lock.lock(); try { // access the shared resource accessResource(); } catch (Exception e) {} finally { lock.unlock(); } public void accessResource() throws InterruptedException {...} |
동시성 버그 중에는 코드를 손상을 주지는 않지만, 애플리케이션의 성능에 악영향을 줄 수 있는 것들이 있다.
목록 5에 있는 동기화 블록을 생각해 보자.
목록 5. 불변 코드가 있는 동기화된 블록
public class Operator {
private int generation = 0; //shared variable
private float totalAmount = 0; //shared variable
private final Object lock = new Object();
public void workOn(List<Operand> operands) {
synchronized (lock) {
int curGeneration = generation; //requires synch
float amountForThisWork = 0;
for (Operand o : operands) {
o.setGeneration(curGeneration);
amountForThisWork += o.amount;
}
totalAmount += amountForThisWork; //requires synch
generation++; //requires synch
}
}
}
|
목록 5에 있는 두 개의 공유 변수에 대한 액세스는 올바르게 동기화되지만, 자세히 살펴보면 동기화된 블록에는 적정 수준보다 더 많은 연산이
필요하다는 사실을 알 수 있다. 목록 6에 표시된 바와 같이 관련 행을 다시 정렬하여 이러한 문제를 수정할 수 있다.
목록 6. 불변 코드가 없는 동기화된 블록
public void workOn(List<Operand> operands) {
int curGeneration;
float amountForThisWork = 0;
synchronized (lock) {
int curGeneration = generation++;
}
for (Operand o : operands) {
o.setGeneration(curGeneration);
amountForThisWork += o.amount;
}
synchronized (lock)
totalAmount += amountForThisWork;
}
}
|
멀티코어 시스템에서는 두 번째 코드가 훨씬 더 잘 수행된다. 목록 5에 있는 동기화된 블록이 병렬 실행을 방해하기 때문이다.
이 메소드의 연산 시간은 주로 루프에서 소비된다. 목록 6에서는 루프가 동기화된 블록 밖에 있기 때문에 다수의 스레드가 이 루프를 병렬로 실행할 수 있다.
가능한 동기화된 블록을 간결하게 하는 것이 스레드 안전성에 일반적으로 유익하다.
두 개의 테이블이 있는 애플리케이션에서 작업 중이라고 가정하자.
하나는 직원 이름을 일련 번호에 맵핑하는 테이블이고 다른 하나는 일련 번호를 봉급에 맵핑하는 테이블이다.
이 데이터는 동시 액세스와 업데이트를 지원해야 한다.
목록 7에 표시된 바와 같이 이러한 기능은 스레드로부터 안전한 ConcurrentHashMap을 통해 지원할 수 있다.
목록 7. 2단계 액세스
public class Employees {
private final ConcurrentHashMap<String,Integer> nameToNumber;
private final ConcurrentHashMap<Integer,Salary> numberToSalary;
... various methods for adding, removing, getting, etc...
public int geBonusFor(String name) {
Integer serialNum = nameToNumber.get(name);
Salary salary = numberToSalary.get(serialNum);
return salary.getBonus();
}
}
|
이 솔루션은 스레드로부터 안전해 보이지만, 사실상 그렇지 않다. getBonusFor 메소드가 스레드로부터 안전하지 않다는데 문제가 있다.
일련 번호를 가져오는 과정과 일련 번호를 사용하여 봉급을 가져오는 과정 사이에서 또 다른 스레드가 두 테이블에서 직원 데이터를 제거할 수 있다.
이런 경우에는 두 번째 맵 액세스에서 널이 리턴되고 예외가 처리된다.
각 맵을 그 자체로 스레드로부터 안전하게 하는 것만으로는 충분하지 않다. 맵 간에는 의존성이 존재하며 두 맵을 액세스하는 조작 중에는 원자적 액세스가
필요한 것도 있다. 이러한 경우에는 스레드로부터 안전하지 않은 컨테이너(예: java.util.HashMap)를 사용한 다음, 동기화를 명시적으로 사용하여
각 액세스를 보호함으로써 스레드 안전성을 달성할 수 있다. 그런 다음에는 필요에 따라 동기화된 블록에서 두 가지 액세스를 모두 처리할 수 있다.
스레드로부터 안전한 컨테이너 클래스, 즉 클라이언트에 스레드 안전성을 보장하는 데이터 구조를 생각해 보자.
(이 컨테이너 클래스는java.util에 있는 대부분의 컨테이너와 달리 그 클라이언트가 해당 컨테이너의 사용법에 따라 동기화되어야 한다.)
목록 8에서는 수정 가능한 멤버가 데이터를 저장하며 잠금 오브젝트가 이러한 데이터에 대한 모든 액세스를 보호한다.
목록 8. 스레드로부터 안전한 컨테이너
public <E> class ConcurrentHeap {
private E[] elements;
private final Object lock = new Object(); //protects elements
public void add (E newElement) {
synchronized(lock) {
... //manipulate elements
}
}
public E removeTop() {
synchronized(lock) {
E top = elements[0];
... //manipulate elements
return top;
}
}
}
|
이제 또 다른 인스턴스를 취하는 메소드를 추가하고 이 메소드의 모든 요소를 현재의 인스턴스에 추가하도록 하자.
이 메소드는 두 가지 인스턴스에 있는 elements 멤버에 액세스해야 하므로 목록 9에 표시된 바와 같이 이 메소드는 두 가지 잠금을 취한다.
목록 9. 이렇게 하면 교착 상태에 빠짐
public void addAll(ConcurrentHeap other) {
synchronized(other.lock) {
synchronized(this.lock) {
... //manipulate other.elements and this.elements
}
}
}
|
교착 상태가 발생할 가능성이 있는가? 프로그램에 두 개의 인스턴스, 인스턴스 간의 순서를 결정함으로써 대칭적 잠금 교착 상태를 방지할 수 있으므로 두 개의 인스턴스가 서로 잠금을 취해야 할 경우에는 그 순서를 동적으로 |
대부분의 Java 개발자가 멀티코어 환경에 적합한 동시 프로그램을 작성하는 방법을 배우는 초기 단계에 있다.
이 과정에서 대부분의 개발자는 본래 더욱 복잡한 멀티스레드 프로그래밍을 하기 위해 익힌 싱글스레드 프로그래밍 이디엄을 포기한다.
동시성 버그 패턴을 연구하는 것은 멀티스레드 프로그래밍의 함정을 발견할 수 있는 좋은 방법이며 미묘한 멀티스레드 이디엄에 익숙해지는 데 도움이 된다.
코드를 작성하거나 코드를 검토하는 과정에서 특정 신호가 위험 신호로 역할을 하게 되도록 버그 패턴을 여러 개의 버그가 결합된 것으로 인식하는 것을
배울 수 있다. 또한, 이러한 목적으로 정적 분석 도구를 사용할 수 있다. FindBugs는 코드에 있을 가능성이 있는 버그 패턴을 찾는 오픈 소스 정적 분석 도구이다. 사실상, FindBugs는 이 기사에서 살펴본 두 번째와 세 번째 버그 패턴을 찾는데 사용될 수 있다.
정적 분석 도구는 잘못된 알람을 생성한다는 한 가지 단점이 있는 것으로 알려져 있다.
따라서 버그가 별로 없는 코드 패턴을 확인할 때보다는 더 많은 시간이 소요될 수 있다.
새롭게 부각되고 있는 동적 분석 도구는 동시성 프로그래밍을 테스트하는데 특히 적합하다.
IBM® Multicore Software Development Kit(MSDK) 및 ConcurrentTesting(ConTest)과 같은 도구를 alphaWorks에서 무료로 사용할 수 있다.
교육
- Java Concurrency in Practice(Brian Goetz; Addison-Wesley, 2006년)
: Brian Goetz가 쓴 이 우수한 책에는 다수의 인스턴스를 대상으로 동기화를 할 때 교착 상태를 방지할 수 있는 방법이 설명되어 있다. - Java theory and practice
: Goetz가 장기간 작성해 온 이 developerWorks 시리즈는 스레드 풀과 작업 큐(2002년 7월),java.util.concurrent.lock(2004년 10월),
휘발성 변수(2007년 6월) 및java.util.concurrent의 포크 - 조인(2007년 11월)에 대한 깊이 있는 설명을 포함하여 동시성에 대한 조언을
확인할 수 있는 또 다른 기사이다. - "5 things you didn't know about ... java.util.concurrent, Part 1"(Ted Neward, developerWorks, 2010년 5월)
: 동시성 프로그래밍에 필요한CopyOnWriteArrayList,BlockingQueue및ConcurrentMap과 같은 클래스를 사용하여 표준 Java 콜렉션 클래스를
갱신하는 방법을 확인하자. - "Resolve common concurrency problems with GPars"(Alex Miller, developerWorks, 2010년 9월)
: Groovy 기반 동시성 라이브러리인 GPars에서는 포크/조인, 액터, 에이전트 및 실행기와 같은 동시성 프로그래밍 모델이 모두 캡슐화된다. - Jetty-1187: Non-atomic self-increment operation on volatile field _set in class SelectorManager
: 이 버그 보고서에는 이 기사에서 살펴본 Jetty 안티패턴과 이를 해결할 수 있는 방법이 자세하게 설명되어 있다. - "FindBugs, Part 1: Improve the quality of your code"(Chris Grindstaff, developerWorks, 2004년 5월)
: 우수한 정적 분석 도구가 도구 상자에 추가해 둘만 한 가치가 있는 이유를 확인하고 그 중 가장 우수한 도구를 사용하는 방법을 배우자. - "IBM intros Multicore SDK"(Dr Dobb's Journal, 2009년 7월)
: 멀티코어 플랫폼에서 병렬 프로그램을 개발하는 데 필요한 IBM alphaWorks 툴킷에 대한 개요를 살펴보자. - 이런 기술 주제와 다른 기술 주제에 대한 서적 정보는 Java technology bookstore를 참조한다.
- developerWorks Java 기술 영역: Java 프로그래밍과 관련된 모든 주제를 다루는 여러 편의 기사를 찾아보자.
제품 및 기술 얻기
- IBM Multicore SDK
: 이 툴킷은 Java 멀티스레드 프로그램에서 데이터 경쟁, 교착 상태 및 잠금 경합을 찾는 데 사용될 수 있다. - IBM ConcurrentTesting 도구
: 멀티스레드 애플리케이션의 유닛 테스트에 사용되는 ConcurrentTesting은 병렬 및 분산 Java 프로그램에서 동시성 관련 버그를 제거하는 데
도움이 된다.
토론
- My developerWorks 커뮤니티에 참여하자.
개발자가 이끌고 있는 블로그, 포럼, 그룹 및 Wiki를 살펴보면서 다른 developerWorks 사용자와 의견을 나눌 수 있다.
'IT_Programming > Java' 카테고리의 다른 글
| GC Dump 보기 (0) | 2011.05.19 |
|---|---|
| Java Closure Example (0) | 2011.05.12 |
| JVM의 DNS 캐시 (0) | 2011.04.03 |
| 커스텀 DecoratorMapper를 이용한 SiteMesh URL 패턴 매칭 기능 확장 (0) | 2011.04.03 |
| Java Database Connectivity에 대해 모르고 있던 5가지 사항 (0) | 2011.03.29 |