Chapter 13 - 쓰레드(Thread)

Chapter 13 - 쓰레드(Thread)

1. 프로세스와 쓰레드

• process : 실행 중인 프로그램
  • OS로부터 실행에 필요한 자원(메모리)을 할당받은 후 프로세스가 됨
  • 데이터, 메모리 등의 자원, 쓰레드로 구성
  • 쓰레드가 프로세스의 자원을 이용해서 실제 작업 수행
  • 모든 프로세스에선 최소 하나의 쓰레드가 존재
  • 둘 이상의 쓰레드를 가지면 멀티쓰레드 프로세스
  • 메모리 한계에 따라 생성할 수 있는 쓰레드 수가 결정

멀티태스킹과 멀티쓰레딩

• 대부분의 OS는 멀티태스킹 지원
  • 여러 개의 프로세스가 동시에 실행 가능
• 멀티캐스팅처럼 멀티 쓰레딩은 하나의 프로세스 내에서 여러 쓰레드가 동시에 작업을 수행
  • 코어가 아주 짧은 시간 동안 여러 작업을 번갈아가며 수행함 -> 모두 동시에 수행되는 것처럼 느껴짐
  • 예) 파일 다운로드를 하면서 메신저를 하는 행동
• 많은 쓰레드를 가진다고 프로세스의 성능이 올라가는 것은 아님

멀티쓰레딩의 장단점

• 장점
  • CPU 사용률 향상
  • 자원을 더 효율적으로 사용
  • 사용자에 대한 응답성 향상
  • 작업이 분리되어 코드가 간결해짐
  • 프로세스를 생성하는 것에 비해 쓰레드를 생성하는 것이 더 적은 시간과 공간 필요
• 단점
  • 여러 쓰레드가 같은 프로세스의 자원을 공유하므로 동기화, 교착상태 문제들을 고려해야 함
  • 교착상태 : 두 쓰레드가 서로 필요한 자원을 점유한 상태에서 기다리느라 지원이 멈춰지는 상황

2. 쓰레드의 구현과 실행

• 구현 내용은 run() 메서드의 몸통에 구현
• Thread 클래스를 상속

  class MyThread extends Thread{
    public void run(){
      // 구현 내용
    }
  }

• Ruunnable 인터페이스를 구현
  • 다른 클래스를 상속받을 수 있으므로 이 방법을 더 선호

  class MyThread implements Runnable{
    public void run(){
      // 구현 내용
    }
  }

• 두 방식은 인스턴스 생성 방식이 다름
  • Thread 클래스를 상속받는 경우엔 new 연산자로 생성
  • Runnable 인터페이스를 구현한 경우 new Thread() 생성자의 매개변수로 제공해야 함
• 쓰레드 내부 코드에서 run 호출 시 Runnable의 run()을 호출하게 해놨으므로 run() 메소드를 오버라이딩 할 필요가 없음
• 단 Runnable 인터페이스를 구현한 경우엔 Thread 클래스의 메서드를 직접 호출할 순 없음
  • 제공된 static currentThread()를 호출하여 쓰레드에 대한 참조를 가져와야 함
  • ex) Thread의 이름을 알고 싶을 땐 Thread.currentThread().getName() 호출
• 쓰레드의 이름은 생성자 및 메서드로 변경 가능, 지정을 안 하면 Thread-번호

쓰레드의 실행 - start()

• run()을 구현했다고 쓰레드가 실행되는 것이 아님
• start()로 쓰레드를 호출해야만 실행
  • 실행되기보단 실행 대기로 바뀌고 자신의 차례가 되어야 실행
• 한 번 종료된 쓰레드는 다시 실행할 수 없음
  • 한 번 더 작업을 수행하기 위해선 new 생성자로 새로운 인스턴스를 생성 후 실행

3.start()와 run()

• start()는 새로운 쓰레드가 작업을 실행하는데 필요한 호출 스택을 생성 후 run()을 호출
• 두 개 이상의 호출 스택이 존재할 땐 스케줄러가 정한 순서에 의해서 교대로 실행
  • 호출 스택의 가장 위에 있는 메서드가 실행 (나머지 메서드는 대기)
  • 주어진 시간 내로 작업을 마치지 못한다면 자신의 차례가 돌아올 때까지 대기

main 쓰레드

• main 메서드의 작업 또한 쓰레드가 실행 -> main 쓰레드라고 부름
  • 프로세스가 최소로 필요한 쓰레드
• main 쓰레드는 사용자 쓰레드이며 실행 중인 사용자 쓰레드가 하나도 없을 때 프로그램은 종료
• 한 쓰레드에서 예외 발생 종료 시 다른 쓰레드에는 영향을 미치지 않음
• start()가 아닌 run() 호출 시 쓰레드가 생성되지 않고 run() 호출 후 호출 스택에 쌓임

4. 싱글쓰레드와 멀티쓰레드

두 개의 작업을 하나의 쓰레드로 처리하는 경우와 두 개의 쓰레드로 처리하는 경우

• CPU만을 사용하는 싱글 코어에선 멀티쓰레드 보다 싱글 쓰레드로 프로그래밍 하는 것이 효율적
  • 처리 시간은 동일하게 걸리지만 멀티쓰레드는 컨텍스트 스위칭의 시간도 추가되고 한 쓰레드가 다른 쓰레드의 출력이 끝나기를 기다려야 하므로 더 오래 걸린다.
  • 컨텍스트 스위칭 시 다음에 실행해야 할 위치인 PC 등의 정보를 저장하고 읽어온다.
  • 프로세스 컨텍스트 스위칭보단 쓰레드 컨텍스트 스위칭이 더 적은 시간이 소요된다.
• 싱글 코어일 때와는 다르게 멀티 코어 일 때는 두 쓰레드가 수행될 수 있으므로 겹치는 부분이 발생
  • 화면 등의 자원을 놓고 쓰레드가 경쟁
• 실행 중인 프로세스는 이 OS 프로세스 스케줄러의 영향을 받음
  • JVM이 쓰레드 스케줄러로 쓰레드의 실행 순서 및 실행 시간이 결정되는 것처럼 프로세스도 OS의 프로세스 스케줄러로 결정
  • 자바는 OS 독립적이지만 실제로 쓰레드는 OS에 종속적
• 두 쓰레드가 서로 다른 자원을 사용하는 경우에는 멀티 쓰레드 프로세스가 더 효율적
  • 데이터를 입력받는 작업, 네트워크로 파일을 주고받는 작업 등등 외부기기와의 입출력이 필요할 때
  • 싱글 쓰레드에서는 외부의 입력을 기다리는 동안 아무런 작업도 할 수 없음
  • 두 개의 쓰레드에서는 사용자의 입력을 기다리는 동안 다른 쓰레드가 작업을 처리

5. 쓰레드의 우선순위

• 우선순위 값에 따라 쓰레드가 얻는 실행 시간이 달라짐

쓰레드의 우선순위 지정하기

• 우선순위의 범위는 1~10이며 숫자가 높을수록 우선순위가 높아짐
• 쓰레드를 생성한 쓰레드로부터 우선순위를 상속받음
  • main 메서드를 수행하는 쓰레드는 우선순위가 5
• void setPriority(int newPriority) : 쓰레드의 우선순위를 지정한 값으로 변경
• int getPriority() : 쓰레드의 우선순위를 반환
• 멀티 코어에서는 쓰레드의 우선순위에 따른 차이가 거의 없음
  • 그저 더 많은 실행 시간과 실행 기회를 갖게 될 것이라고 기대할 수밖에 없음
  • PriorityQueue를 사용하여 우선순위가 높은 작업을 먼저 처리하도록 구현하는 게 더 나을 수도 있음

6. 쓰레드 그룹(thread group)

• 쓰레드 그룹은 서로 관련된 쓰레드를 그룹으로 다루기 위한 것
  • 폴더를 생성해서 관련된 파일을 관리하는 것과 비슷함
• 쓰레드 그룹에 다른 쓰레드 그룹을 포함 시킬 수 있음
• 쓰레드 그룹은 보안상의 이유로 도입
  • 자신이 속한 쓰레드 그룹이나 하위 쓰레드 그룹만 변경하도록 하기 위해
• ThreadGroup을 사용하여 생성
• 모든 쓰레드는 반드시 쓰레드 그룹에 포함되어야 함
  • 쓰레드 그룹을 지정하는 생성자를 사용하지 않는 쓰레드는 자신을 생성한 쓰레드와 같은 그룹에 속하게 됨
  • 그러므로 우리가 만드는 모든 쓰레드는 main 쓰레드 그룹의 하위
• JVM은 어플리케이션 실행 시 main과 system이라는 쓰레드 그룹 생성
  • main 메서드를 수행하는 쓰레드는 main 그룹에 속함
  • 가비지 컬렉션을 수행하는 Finalizer 쓰레드는 system 그룹에 속함
• ThreadGroup getThreadGroup() : 쓰레드 자신이 속한 그룹 반환
• void uncaughtException(Tread t, Throwable e) : 쓰레드 그룹의 쓰레드가 처리되지 않는 예외에 의해 실행이 종료되었을 때, JVM에 의해 이 메서드가 자동으로 호출

7. 데몬 쓰레드(daemon thread)

• 일반 쓰레드의 작업을 돕는 보조적인 역할 수행
  • 일반 쓰레드가 모두 종료될 시 데몬 쓰레드도 자동 종료
  • 예로는 가비지 컬렉터, 자동 저장, 화면 자동갱신 등등
• 특정 조건이 만족되면 수행 후 다시 대기
• 실행하기 전 setDaemon(true)를 호출
  • 쓰레드를 데몬 쓰레드나 사용자 쓰레드로 변경하는 메서드
  • 반드시 start()를 호출하기 전에 실행시킬 것
• 데몬 쓰레드가 생상한 쓰레드는 자동으로 데몬 쓰레드가 됨
• boolean isDaemon() 메서드로 쓰레드가 데몬 쓰레드인지 확인
• 프로그램을 시작 시 보조 작업을 하는 많은 데몬 쓰레드들이 실행됨
  • 각자 system 쓰레드 그룹, main 쓰레드 그룹에 속해있음

8. 쓰레드의 실행 제어

• 쓰레드의 상태
  • NEW : 쓰레드가 생성되고 start() 호출되기 전
  • RUNNALBE : 실행 중 or 실행 가능 상태
  • BLOCKED : 동기화 블럭에 의해 일시정지된 상태
  • WAITING, TIMED_WAITING : 쓰레드의 작업이 종료되지는 않았지만 실행 가능하지 않은 일시정지 상태 (TIME_WATING은 일시정지시간이 지정)
  • TERMINATED : 쓰레드의 작업이 종료된 상태
• 쓰레드의 생성부터 소멸 과정
  • start()를 호출하면 실행 대기열에 저장 후 자기 차례 기다림 (실행 대기열은 큐와 같은 구조)
  • 자신의 차례가 되면 실행상태
  • 주어진 실행 기간이 다되는 경우나 yield()를 만나면 실행 대기 상태로 다시 실행 대기열로 들어감
  • 실행 중 suspend(), sleep(), wait(), join(), I/O block에 의해 일시정지가 될 수 있음
  • 지정된 일시정지 시간이 다 되는 경우, notify(), resume(), interrupt()가 호출되면 일시정지를 벗어나서 다시 실행 대기열로 들어감
  • 실행을 모두 마치는 경우, stop()을 호출하는 경우 쓰레드 소멸

sleep(long millis) - 일정 기간 동안 쓰레드를 멈추게 함

• 두 번째 파라미터를 넣을 시 나노세컨드까지 지정 가능
• static 메서드
  • 참조변수와 상관 없이 현재 실행 중인 쓰레드에 대해 작동
  • 참조변수를 이용하기보단 Thread.sleep()으로 사용할 것
• 시간이 다 되거나 interrupt()를 호출해야 잠에서 깨어나 실행 대기 상태로 바뀜
• 항상 try-catch 문으로 예외 처리 필요
  • InterruptedException은 런타임 예외가 아니므로
  • try-catch 문을 다루는 메서드를 만들어서 사용하기도 함

interrupt()와 interrupted() - 쓰레드의 작업을 취소한다.

• interrupt()는 쓰레드에게 작업을 멈추라고 요청
  • 쓰레드를 강제로 종료시키지는 못함
  • 인스턴스 변수인 interrupted의 상태를 변경하는 것뿐 (true로)
• interrupted() 메서드로 쓰레드에 대해 interrupt가 호출되었는지 확인 가능 (interrupted의 상태를 호출해서)
  • 그 후 interrupted의 상태를 false로 변경
  • isInterrupted()는 쓰레드의 interrupted를 확인하는 것인 동일하지만 상태 변경 X
• sleep(), wait(), join()에서 interrupt() 호출 시 실행 대기 상태로 바뀜
  • 멈춰있을 때 interrupt()를 호출하면 InterruptedException이 발생되고 쓰레드의 interrupted의 상태는 false로 자동 초기화

suspend(), resume(), stop()

• suspend()는 sleep()처럼 쓰레드를 멈추게 함
  • resume()을 호출하면 다시 실행 대기 상태
  • stop()은 호출되는 즉시 쓰레드가 종료
• suspend()와 stop()이 교착상태를 일으키기 쉽게 작성되었으므로 사용 권장 X
  • deprecated 되어 있음
• suspend와 stop이 동작하지 않을 시 변수 앞에 volatile 선언

yield() - 다른 쓰레드에게 양보한다.

• yield()는 쓰레드 자신에게 주어진 실행 시간을 다음 차례의 쓰레드에게 양보
  • 할당받은 실행 시간을 사용하던 중 yield()를 만나면 나머지 실행 시간은 포기하고 다시 실행 대기 상태
• 프로그램의 응답성을 높이고 효율적인 실행을 위해 사용
  • 쓰레드가 실행을 멈추게 한 상태에서 while이 반복된다면 바쁜 대기 상태(busy wating)로 실행 시간을 의미 없이 낭비
  • 이때 yield()를 호출해서 남은 시간을 while

join() - 다른 쓰레드의 작업을 기다린다.

• 쓰레드 자신의 하던 작업을 잠시 멈추고 다른 쓰레드가 지정된 시간 동안 작업을 수행하도록 할 때 join()을 사용
• 시간을 지정할 수 있고 지정하지 않으면 해당 쓰레드가 모두 마칠 때까지 기다림
• join()도 interrupt()에 의해 벗어날 수 있음
  • sleep()과 다른 점은 현재 쓰레드가 아닌 특정 쓰레드에 대해 동작

9. 쓰레드의 동기화

• 멀티쓰레드 프로세스는 여러 쓰레드가 같은 프로세스 내의 자원을 공유해서 작업
  • 서로의 작업에 영향을 줌
  • 작업하던 공유 데이터를 다른 쓰레드가 변경하면 의도한 것과 다른 결과가 나올 수도 있음
  • 다른 쓰레드에게 방해받지 않도록 나온 것이 임계 영역(critical section), 락(lock)
  • 공유 데이터를 사용하는 코드 영역을 임계 영역으로 지정
  • 락을 획득한 단 하나의 쓰레드만 임계 영역 내의 코드를 수행할 수 있게 함
  • 이렇게 다른 쓰레드가 작업에 간섭을 못 하게 하는 것을 쓰레드의 동기화(synchronization)이라고 부름

9.1 synchronized를 이용한 동기화

• 동기화의 두 가지 방식
  • 메서드 전체를 임계 영역으로 지정
  • 특정한 영역을 임계 영역으로 지정 (이때의 블럭을 synchronized 블럭이라고 부름)
  • 둘 다 lock을 얻어야 접근 가능하고 벗어날 시 lock을 반납한다.
  • 모든 객체는 lock을 하나씩 가지고 있다.
  • 메서드 전체의 lock보단 블럭 단위별로 임계 영역을 최소화하는 것이 효율적
  • 동기화에 들어가는 변수들은 private로 설정할 것 (private이 아니면 동기화를 해도 값의 변경을 막을 방법이 없다.)

9.2 wait()과 notify()

• wait()
  • 동기화된 임계 영역의 코드를 수행하다가 더 이상 작업을 진행할 상황이 아니면 wait() 호출 후 락을 반납하고 쓰레드를 기다리게 한다.
  • 매개변수를 넣으면 지정된 시간 동안만 기다림
  • 매개변수가 없을 시 notify()가 호출될 때까지 기다림
• notify()
  • 기다리고 있는 쓰레드들에게 통지를 하여 락을 얻어 작업을 진행할 수 있게 한다.
  • 쓰레드들은 객체의 대기실(waiting pool)에서 통지를 기다린다.
  • 해당 객체의 대기실에 있던 모든 쓰레드 중에서 임의의 쓰레드만 통지를 받음
  • notifyAll()은 기다리고 있는 모든 쓰레드들(호출된 객체의 waiting pool에 있는)에게 통보, 하지만 lcok을 얻을 수 있는 쓰레드는 단 하나
• wait(), notify()는 Object 클래스에 정의 (특정 객체에 대한 것이므로)

기아 현상과 경쟁 상태

• 한 쓰레드가 계속 통지를 받지 못하고 오랫동안 기다리게 되는 현상을 기아(starvation) 현상이라고 함
• notify() 대신 notifyAll()을 사용해서 막을 수 있음
• 여러 쓰레드가 통지를 받아서 lock에 대해 경쟁하는 상태를 경쟁 상태(race condtion)
  • 경쟁 상태를 개선하기 위해 쓰레드를 구별해서 통지해야 함 (Lock과 Condition 이용)

9.3 Lock과 Condition을 이용한 동기화

• synchronized 블럭 외에도 java.util.concurrent.locks 패키지의 lcok 클래스들을 이용
  • JDK 1.5에서 추가
• ReentrantLock : 재진입이 가능한 lock. 가장 일반적인 배타 lock
  • 재진입은 lock을 푼 뒤 추후에 다시 lock을 얻어 접근을 의미
• ReentrantReadWriteLock : 읽기에는 공유적, 쓰기에는 배타적인 lock
  • 읽기 lock과 쓰기 lock을 제공
  • 읽기 lock은 중복해서 걸고 읽기 수행 가능
  • 읽기 lock이 걸린 상태에서 쓰기 lock을 거는 것은 허용 X (반대도 허용 X)
• StampedLock : ReentrantLock에 낙관적인 lock의 기능을 추가
  • lock을 걸거나 해지할 때 스탬프를 사용
  • 스탬프는 long타입의 정숫값
  • 낙관적 읽기 lock은 쓰기 lock에 의해 바로 풀림
  • 낙관적 읽기에 실패하면 읽기 lock을 얻어서 다시 읽어 와야 함 (무조건 읽기 lock을 걸지 않고 쓰기와 읽기가 충돌할 때만 쓰기가 끝난 후에 읽기 lock을 걸음)

ReentrantLock의 생성자

• 종류
  • ReentrantLock()
  • ReentrantLock(boolean fair)
• 생성자의 매개변수를 true로 주면 lock이 풀렸을 때 가장 오래 기다린 쓰레드가 lock을 획득
  • 어떤 쓰레드가 오래 기다렸는지 연산 필요하므로 성능 떨어짐
  • 대부분 공정함보다 성능을 선택
• synchronized와 달리 lock 클래스들은 수동으로 lock을 잠그고 해제해야 함 (빼먹지 않도록 주의)
  • void lock() : lock을 잠금
  • void unlock() : lock을 해지
  • boolean isLocked() : lock이 잠겼는지 확인
  • 예외 발생 및 return 문으로 빠져나갈 수 있으므로 try-finally 문으로 감싸는 것이 일반적
• tryLock : 다른 쓰레드에 의해 lock이 걸려 있으면 lock을 얻으려고 기다리지 않거나 지정된 시간만큼만 기다림
  • interrupt()에 의해 작업이 취소될 수 있도록 작성됨 (InterruptedException 발생 가능)

ReentrantLock과 Condition

• 각 쓰레드를 위한 Condition을 만들어서 각각의 wating pool에서 따로 기다리도록 할 수 있음
• Condotion은 이미 생성된 lock으로부터 newCondition()을 호출해서 생성
  • 그 후 await() & signal()을 사용하면 됨
  • 대상을 명확히 구분할 수 있음

9.4 volatile

• 멀티 코어 프로세서에서는 코어마다 별도의 캐시를 가지고 있음
  • 코어는 메모리에서 읽어온 값을 캐시에 저장하고 캐시에서 값을 읽어서 작업
  • 캐시에 저장된 값이 갱신되지 않아서 메모리에 저장된 값이 다른 경우 발생
  • 이때 volatile을 변수 앞에 붙이면 캐시가 아닌 메모리에서 코어가 값을 읽어옴
• volatile을 붙이는 대신에 synchronized 블럭을 사용해도 같은 효과
  • 쓰레드가 synchronized 블럭으로 들어갈 때와 나올 때 캐시와 메모리 간의 동기화가 이루어지기 때문

volatile로 long과 double을 원자화

• JVM이 데이터를 한 번에 처리하는 최소 단위는 4byte
  • 4byte보다 큰 long과 double 타입(8byte)는 변수를 읽는 과정에 다른 쓰레드가 끼어들 여지가 있음 (하나의 명령어로 값을 쓰거나 읽을 수 없으므로)
  • 변수를 선언할 때 volatile을 붙이면 이러한 문제 해결
• volatile는 해당 변수에 대한 읽기, 쓰기를 원자화
  • 상수는 변하지 않는 값이므로 tread-safe임으로 volatile을 붙일 필요가 없고 붙일 수도 없음
  • 변수의 읽기나 쓰기를 원자화할 뿐 동기화가 아니라는 점에 주의(필요한 메서드나 블럭은 동기화를 해야 한다.)

9.5 fork & join 프레임웍

• 멀티 코어를 잘 활용할 수 있는 멀티 쓰레드 프로그래밍이 중요해짐
  • JDK 1.7부터 fork & join 프레임웍을 추가
  • 하나의 작업을 작은 단위로 나눠서 여러 쓰레드에서 동시에 처리하는 것을 쉽게 만들어줌
• 두 클래스 중 하나를 상속받아서 구현
  • RecursiveAction : 반환값이 없는 작업 구현
  • RecursiveTask : 반환값이 있는 작업을 구현
• compute() 추상 메서드를 구현해야 함
  • run()과 start()의 관계처럼 invoke()로 호출을 해야 작업을 실행
• fork & join 프레임웍에서 제공하는 ForkJoinPool이라는 쓰레드풀에서 쓰레드를 사용
  • 지정된 수의 쓰레드를 미리 생성한 뒤 반복해서 재사용 가능
  • 반복 생성 억제, 적당한 쓰레드 생성 (성능을 저하시킬 정도로 쓰레드를 만들지 않음)
  • 각 쓰레드는 자신의 작업 큐에 담긴 작업 순서대로 처리

다른 쓰레드의 작업 훔쳐 오기

• 자신의 작업 큐가 비어있는 쓰레드는 다른 쓰레드의 작업 큐에서 작업을 가져와서 수행
• 쓰레드풀에 의해 자동적으로 이루어짐
• 여러 쓰레드가 골고루 작업을 나누어 처리

fork()와 join()

• fork() : 해당 작업을 쓰레드 풀의 작업 큐에 넣는 비동기 메서드
  • 비동기 메서드는 다른 쓰레드에게 작업을 수행하도록 지시만 하고 결과를 기다리지 않음
• join() : 해당 작업의 수행이 끝날 때까지 기다렸다가 수행이 끝나면 결과를 반환하는 동기 메서드