[이펙티브 자바] 11장 : 동시성

스레드는 여러 활동을 동시에 수행할 수 있게 해준다. 하지만 동시성프로그래밍은 어렵고 잘못될 수 있는 일이 늘어나며 문제를 재현하기도 어렵다 (디버깅이 어렵다)

하지만, 어렵다고 피해서는 안된다. 오늘날 널리 쓰이는 다중코어 프로세서의 힘을 제대로 활용하려면 반드시 내것으로 만들어야만 하는 기술이다.

아이템 78 : 공유 중인 가변 데이터는 동기화해 사용하라

동기화의 기능

• 배타적 실행

많은 프로그래머가 동기화를 배타적 실행, 즉 한 스레드가 변경하는 중이라서 상태가 일관되지 않은 순간의 객체를 다른 스레드가 보지 못하게 막는 용도로만 생각한다.

일관된 객체 생성 → 접근하는 메서드가 객체에 락을 검 → 락을 건 메서드가 객체의 상태를 확인하고 수정함 ⇒ 객체를 하나의 일관된 상태에서 다른 일관된 상태로 변화시키는 과정

동기화를 제대로 사용하면 어떤 메서드도 이 객체의 상태가 일관되지 않은 순간을 볼 수 없다.

동기화의 또 다른 중요한 기능! → 동기화는 스레드 사이의 안정적인 통신에 꼭 필요하다.

• 스레드 사이의 안정적인 통신

공유중인 가변 데이터가 원자적(long, double..)으로 읽고 쓸 수 읽을지라도 동기화에 실패하면 처참한 결과로 이어진다.

public class StopThread {
  	private static boolean stopRequested;
  
  	public static void main(String[] args) {
      	Thread backgroundThread = new Thread(() -> {
          int i = 0;
          while (!stopRequested) // 특정 가상머신이 최적화 수행하면 무한히 실행됨. 스레드간 통신 불가능
            	i++;
        })
        backgroundThread.start();
      	
      	TimeUnit.SECONDS.sleep(1);
      	stopRequested = true;
    }
}

위 코드는 메인쓰레드가 공유변수를 true로 바꾸면 1초안에 백그라운드스레드가 종료되길 기대하지만 실제로는 계속해서 돌아간다.

그 원인은 동기화이다. 동기화하지않으면 메인 스레드가 수정한 값을 백그라운드가 어느 시점에 보게 될지 보장할 수 없다. 또한 최적화가 진행되어 예상과 다른 흐름으로 이어질 수 있다.

• 최적화로 흐름이 달라진 코드

// 원래 코드
while (!stopRequested)
	i++;

// 최적화 코드
if (!stopRequuested)
	while(true)
		i++;

최적화로 인해 공유 변수 값이 바껴도 중지되지 않고 실행된다.

이 문제를 해결하려면 쓰기 메서드와 읽기 메서드 모두를 동기화해야만 한다.

→ 쓰기와 읽기 모두가 동기화되지 않으면 동작을 보장하지 않는다.

private static synchronized void requestStop() {
  	stopRequested = true;
}
private static synchronized boolean stopRequested() {
  	return stopRequested;
}
public static void main(String[] args) {
  Thread backgroundThread = new Thread(() -> {
    int i = 0;
    while (!stopRequested())
      i++;
  })
    backgroundThread.start();

  TimeUnit.SECONDS.sleep(1);
	requestStop();
}

위 코드는 동기화의 기능 중 스레드 간 통신 목적으로 사용되었다.

volatile

위 코드에서 공유변수를 volatile 로 선언하면 동기화를 생략할 수 있다. 배타적 수행과는 상관 없으나, 항상 가장 최근에 기록된 값을 읽게 됨을 보장한다.

• 배타적 실행을 보장하지 않으나 스레드간 통신을 지원하는 것

증감연산자

증감연산자는 atomic하지 않다. 이 연산자는 실제로 필드에 접근해 1)값을 읽고 값을 증감시켜 2)새로운 값을 저장한다.

이 두 접근 사이에 들어와 값을 읽어가면 프로그램이 잘못된 결과를 계산해내는 ‘안전 실패'가 발생한다.

이때 증감연산자가 포함되어 있는 메서드에 synchronized 한정자를 붙이면 문제가 해결된다. (대신 변수에 volatile은 삭제)

AtomicLong

AtomicLong은 락 없이도 스레드 안전한 메서드를 지원한다

• 배타적 실행(원자성)도 보장하고, 스레드간 통신도 보장한다.

예시로는 getAndIncrement() 메서드가 있다. (안전한 증감연산)

동시성 문제를 피하는 가장 좋은 방법은 애초에 가변 데이터를 공유하지 않는 것이다. (불변 데이터만 공유하면 문제가 발생하지 않는다) ⇒ 가변 데이터는 단일 스레드에서만 쓰도록 하자.

-핵심 정리- : 여러 스레드가 가변 데이터를 공유한다면 그 데이터를 읽고 쓰는 동작 모두를 반드시 동기화 해야한다.

아이템 79 : 과도한 동기화는 피하라

과도한 동기화는 성능을 떨어뜨리고, 교착상태에 빠뜨리며, 예측할 수 없는 동작을 야기한다.

• 응답 불가와 안전 실패를(동시성 문제) 피하려면 동기화 메서드나 동기화 블록 안에서는 제어를 절대로 클라이언트에 양도하면 안된다.
  • 오버라이딩 가능한 메서드는 호출하면 안된다
  • 클라이언트가 넘겨준 함수 객체를 호출하면 안된다.
• 동기화 영역에서는 가능한 일을 적게 하는 것이 좋다.
  • 오래 걸리는 작업이라면 동기화 영역 밖으로 옮겨보자.
  • 동기화가 길어질수록 병렬로 실행할 기회를 읽고 코드 최적화 기회도 잃게 된다.
• 가변 클래스를 작성하려거든 다음 두 선택지 중 하나를 따르자.
  1. 동기화를 하지 말고, 해당 클래스를 동시에 사용해야 하는 클래스가 외부에서 알아서 동기화하게 하자 (StringBuilder)
  2. 동기화를 내부에서 수행해 스레드 안전한 클래스로 만들자. (StringBuffer)

선택하기 어렵다면 동기화 하지말고 문서에 ‘스레드 안전하지 않다'고 명기하자.

아이템 80 : 스레드보다는 실행자, 태스크, 스트림을 애용하라

실행자(Excutor)를 사용하면 작업 큐를 간단하게 생성하고 스레드 풀을 생성해 여러 병렬처리를 쉽게 할 수 있도록 해준다.

• Task란 작업단위를 나타내는 핵심 추상 개념
  • Runnable (실행)
  • Callable (값을 반환, 예외를 던질 수 있음)

작업 큐를 손수 만드는 일은 삼가야하고, 스레드를 직접 다루는 것도 일반적으로 삼가야한다. 반면 실행자 프레임워크에서는 작업단위와 실행 매커니즘이 분리된다.

아이템 81 : wait와 notify보다는 동시성 유틸리티를 애용하라

wait와 notify는 올바르게 사용하기가 아주 까다로우니 고수준 동시성 유틸리티를 사용하자.

java.util.concurrent의 고수준 유틸리티

• 실행자 프레임워크
• 동시성 컬렉션
  • List, Queue, Map 같은 표준 컬렉션 인터페이스에 동시성을 가미해 구현한 고성능 컬렉션
    • 높은 동시성을 위해 동기화를 내부에서 수행 (동시성 무력화 불가, 외부에 락시 더 느려짐)
  • ConcurrentHashMap은 synchronizedMap보다 훨씬 좋다.
    • 동시성 맵은 동기화된 맵에 비해 성능이 훨씬 좋다.
• 동기화 장치 (synchronizer)
• 시간 간격을 잴 때는 항상 System.currentTimeMillis가 아닌 System.nanoTime을 사용하자
• wait메서드를 사용할 때는 반드시 wait loop 관용구를 사용하라. 반복문 밖에서는 절대로 호출하지 말자

wait와 notify를 직접 사용하는 건 동시성 ‘어셈블리 언어'로 프로그래밍 하는 것에 비유할 수 있다. 반면 java.util.concurrent는 고수준 언어에 비유할 수 있다. 우리는 코드를 새로 작성한다면 이를 사용할 필요가 전혀 없는 것이다.

아이템 82 : 스레드 안정성 수준을 문서화하라

메서드 선언에 synchronized 한정자를 선언할지는 구현 이슈일 뿐 API에 속하지 않는다. 즉, 이것만으로는 스레드 안전하다고 확신하기 어렵다.

• 멀티스레드 환경에서도 API를 안전하게 사용하려면 클래스가 지원하는 스레드 안전성 수준을 정확히 명시해야 한다.
  1. 불변(immutable) : 클래스의 인스턴스는 상수와 같아서 외부 동기화도 필요 없다.
  2. 무조건적 스레드 안전(unconditionally thread-safe) : 클래스의 인스턴스는 수정될 수 있으나, 별도의 외부 동기화 없이 동시 사용해도 안전하다
  3. 조건부 스레드 안전(conditionally thread-safe) : 무조건적 스레드 안전과 같으나, 일부 메서드는 동시에 사용하려면 외부 동기화가 필요하다.
  4. 스레드 안전하지 않음(not thread-safe) : 클래스 인스턴스는 수정될 수 있다. 동시 사용하려면 메서드 호출을 클라이언트가 동기화해야 한다.
  5. 스레드 적대적(thread-hostile) : 모든 메서드 호출을 외부 동기화하더라도 멀티스레드 환경에서 안전하지 않다.

정확한 언어로 설명하거나 스레드 안정성 애너테이션을 사용할 수 있다.

클래스의 스레드 안정성은 보통 클래스의 문서화 주석에 기재한다. 독특한 특성을 가진 메서드라면 해당 메서드의 주석에 기재하도록 한다.

아이템 83 : 지연 초기화는 신중히 사용하라

지연초기화란 필드의 초기화 시점을 그밧이 처음 필요할 때까지 늦추는 기법이다. (스프링 순환 참조 해결 시 사용했던 기억이 난다)

• 주로 최적화 용도에 사용하며 클래스와 인스턴스 초기화 시 발생하는 순환 문제 해결 시에도 사용

성능적으로 지연초기화가 좋은 경우는 해당 클래스의 인스턴스 중 그 필드를 사용하는 인스턴스가 낮으면서 그 필드를 초기화하는 비용이 큰 경우이다.

하지만, 이런 경우가 적고 멀티스레드 환경에 적용하기가 어렵다. 따라서 대부분의 상황에서 일반적인 초기화가 지연 초기화보다 낫다

• 지연초기화 방법
  • 지연초기화가 초기화 순환성을 깨뜨릴 것 같으면 synchronized 접근자를 사용하자
  • 성능 때문에 정적 필드를 지연 초기화해야 한다면 lazy initialization holder class 관용구를 사용하자
  • 능 때문에 인스턴스 필드를 지연 초기화해야 한다면 double-check 관용구를 사용하라

대부분은 지연 초기화를 사용하지 않지만 꼭 필요하다면 올바른 지연초기화 기법을 사용하자.

아이템 84 : 프로그램의 동작을 스레드 스케줄러에 기대지 말라

잘 작성된 프로그램은 스레드 스케줄러에 따라 성능이 요동쳐서는 안된다.

정확성이나 성능이 스레드 스케줄러에 따라 달라지는 프로그램이라면 다른 플랫폼에 이식하기 어렵다.

스레드 수가 지나치게 많다면 스케줄러의 고민거리가 늘어나고 이는 정책에 따라 성능이 달라지게 할 수 있다. 실행 가능한 스레드 수를 적게 유지하는 기법은 각 스레드가 작업을 완료한 후 다음 일거리가 생길 때까지 대기하도록 하는 것이다.

스레드는 당장 처리해야 할 작업이 없다면 실행돼서는 안된다.

• 스레드 풀 크기를 적절히 설정하고 작업은 짧게 유지하자

스레드는 절대 바쁜 대기 상태가 되면 안된다.

• 스레드 스케줄러의 변덕에 취약하고, 프로세서에 큰 부담을 준다.

특정 스레드가 다른 스레드들과 비교해 CPU 시간을 충분히 얻지 못해서 간신히 돌어가는 프로그램을 보더라도 Thread.yield를 써서 문제를 고쳐보려는 유혹을 떨쳐내자

• 테스트할 수단도 없고, 이식성도 낮다.