내일배움캠프 3주차 쓰레드 이어서

오늘의 키워드

• join( ), yield( ), synchronized( )
• wait( ), notify( )
• Lock, Condition

오늘의 내용

• join( )
  • 정해진 시간 동안 지정한 쓰레드가 작업하는 것을 기다린다
  • ms(밀리초) 단위로 설정된다
  • 예외처리를 꼭 해줘야 된다
  • interrupt를 만나면 기다리는 것을 멈추기 때문에 InterruptedException이 발생한다
• yield( ) : 남은 시간을 다음 쓰레드에게 양보하고 자신은 실행대기 상태가 된다
• synchronized( )(동기화)
  • 여러 쓰레드가 한 프로세스의 자원을 공유해서 작업해 서로 영향을 줘 장애나 버그발생을 방지
  • 한 쓰레드가 진행 중인 작업을 다른 쓰레드가 침범하지 못하게 막는다
  • 동기화를 하려면 다른 쓰레드의 침범을 막아야 하는 코드를 임계영역으로 설정한다
  • 임계영역에는 Lock을 가진 단 하나의 쓰레드만 출입 가능하다(Lock을 걸다)
  • wait( ) : 침범을 막은 코드를 수행하다가 작업을 더 이상 진행할 상황이 아니면, wait()을 호출하여 쓰레드가 Lock을 반납
  • notify( ) : 작업을 중단했던 쓰레드가 다시 Lock을 얻어 진행할 수 있게 된다
• Lock : synchronized블럭으로 동기화를 하면 자동적으로 Lock이 걸리고 풀리지만 같은 메서드 내에서만 사용 가능하므로 Lock클래스를 사용하면 이런 제약을 해결할 수 있다
  • ReentrantLock
    • 재진입 가능한 Lock, 가장 일반적인 배타 Lock
    • 특정 조건에서 Lock을 풀고, 나중에 다시 Lock을 얻어 임계영역으로 진입이 가능하다
  • ReentrantReadWriteLock
    • 읽기를 위한 Lock과 쓰기를 위한 Lock을 따로 제공한다
    • 읽기에는 공유적이고 쓰기에는 베타적인 Lock이다
    • 읽기 Lock이 걸려있으면 다른 쓰레드들도 읽기 Lock을 중복으로 걸고 읽기 수행이 가능하다(read-only)
    • 읽기 Lock이 걸려있는 상태에서 쓰기 Lcok을 거는 것은 허용되지 않는다(데이터 변경 방지)
  • StampedLock
    • ReentrantReadWriteLock에 낙관적인 Lcok의 기능을 추가한
    • 낙관적인 Lock : 데이터를 변경하기 전에 락을 걸지 않는 것, 데이터를 변경할 때 충돌이 일어날 가능성이 적은 상황에서 사용한다
    • 낙관적인 Lock을 사용하면 읽기 쓰기 작업이 빠르게 처리된다, 쓰기 작업이 발생했을 때 데이터가 이미 변경된 경우 다시 읽기 작업을 수행해 새로운 값을 읽고 변경작업을 다시 수행한다, 쓰기 작업이 빈번하지 않는 경우 사용해 더 빠른 처리가 가능
    • 낙관적인 읽기 Lock은 쓰기 Lock에 의해 바로 해제 가능하다
    • 무조건 읽기 Lock을 걸지 않고 쓰기와 읽기가 충돌할 때만 쓰기 후 읽기 Lock을 건다

오늘의 회고

• 개인프로젝트 제출 후 하루도 안 지났는데 팀프로젝트 시작이라니 한숨 돌릴 시간도 없다
• 회의 진행하면서 역할분담은 내일 하게 되는데 뽑기를 잘하면 쉬운 걸 하지 않을까라는 기대감이 드는데 쉬운걸 한다고 마냥 좋기만 할까 라는 의문이 들긴 한다
• 팀원 중 한분이 중도하차 하셔서 손이 하나 줄어서 일이 더 많아진듯한 기분?