라이브락 vs 데드락

반응형

이전에 데드락 관련 질문을 한적이 있었습니다. 그 당시 락을 학습을 했었을 때였던걸로 기억합니다. 아무튼 어떤 질문을 했었는데 그거는 데드락이 아니고 라이브락이라는 답변을 받은 적이 있습니다. 지금 이것들이 무엇인지 어떤건지 답변하기 어려워 이번 챕터를 준비를 하였습니다. 라이브락과 데드락의 차이는 무엇일까요? 

데드락 (Deadlock)

Deadlock은 두 단어로 이루어져 있습니다.

  • Dead : 죽은, 멈춘
  • Lock : 잠금, 자물쇠

이를 직역하면 "죽은 잠금", 혹은 "완전히 막혀버린 상태"라는 의미가 됩니다.
여기서 중요한 것은 Dead입니다. 단순히 잠겨 있는 상태가 아니라 더 이상 아무것도 진행되지 않는 상태를 의미합니다.

가장 유명한 예시가 식사하는 철학자 문제입니다. 여러 명의 철학자가 원형 테이블에 앉아 식사를 하고 있습니다.
각 철학자 사이에는 포크가 하나씩 놓여 있습니다. 철학자는 식사를 하기 위해 양쪽 포크 두 개가 필요합니다.
예를 들어 철학자 A가 식사를 하려면 왼쪽 포크, 오른쪽 포크두 개를 모두 들어야 합니다.
그런데 모든 철학자가 동시에 왼쪽 포크를 먼저 집었다고 가정해 보겠습니다.

출처: 나무위키

그 결과는 어떻게 될까요?

  • 철학자 A는 오른쪽 포크를 기다립니다.
  • 철학자 B도 오른쪽 포크를 기다립니다.
  • 철학자 C도 오른쪽 포크를 기다립니다.
  • 철학자 D도 오른쪽 포크를 기다립니다.

하지만 그 오른쪽 포크는 이미 다른 철학자가 잡고 있습니다. 결국 모든 철학자는 다음과 같은 상태가 됩니다.

  • 하나의 포크는 잡고 있음
  • 다른 포크를 기다리는 중

하지만 그 포크는 절대 풀리지 않습니다. 그래서 아무도 식사를 하지 못한 채 영원히 기다리게 됩니다.
이 상태가 바로 데드락(Deadlock) 입니다. 즉, 서로가 가진 자원을 기다리면서 아무도 작업을 진행하지 못하는 상태입니다.

여기서 철학자는 스레드 혹은 트랜잭션일겁니다. 그리고 포크는 공유 자원입니다. 어떻게 보면 되게 탐욕스럽다고 할 수 있죠.
머릿속에서 상상하길 여러 스레드가 하나의 자원을 점유하려고 한다면, 그것을 점유하려고 싸우게 될겁니다. 그렇게 되면 결국엔 아무도 움직이 못하는 상황이 됩니다. 

그렇다면, 데드락이 언제나 발생할까요? 데드락이 발생하는 원인은 총 4가지로 설명할 수 있습니다.

1. 상호 배제 (Mutual Exclusion)

동시에 같은 자원을 사용하는 것은 불가능합니다. 다시 철학자 문제를 생각해봅시다. 
철학자문제에서 2개의 포크를 집어야 식사가 가능했다고 하였습니다. 

1번철학자와 2번 철학자는 동시에 식사를 할 수 없습니다. 왜냐하면 이미 포크를 이미 누군가(1 or2)가 사용하고 있기 때문이죠.
이를 방지하기 위해서는 순차적으로 식사를 하는 방법을 사용해야 할거 같습니다.

2. 점유 대기 (Hold and Wait)

점유 대기(Hold and Wait)는 이미 하나의 자원을 점유한 상태에서 다른 자원을 기다리는 상황을 의미합니다.
다시 식사하는 철학자 문제로 돌아가 보겠습니다. 철학자가 식사를 하기 위해서는 왼쪽 포크와 오른쪽 포크 두 개가 필요합니다.
예를 들어 1번 철학자가 다음과 같은 상황이라고 가정해 보겠습니다.

  • 왼쪽 포크는 이미 집었습니다.
  • 하지만 오른쪽 포크는 다른 철학자가 사용 중입니다.

이 경우 1번 철학자는 어떻게 될까요?
왼쪽 포크는 계속 쥔 상태로 유지하면서, 오른쪽 포크가 사용 가능해질 때까지 기다리게 됩니다.

즉, 하나의 자원은 점유하고 있고 다른 자원은 대기하고 있는 상태 이것이 바로 점유 대기(Hold and Wait) 입니다.
여기서 중요한 점은 자원을 놓지 않는다는 것입니다.
만약 철학자가 다음과 같이 행동한다면 상황은 달라집니다.
오른쪽 포크가 없으면 왼쪽 포크도 내려놓는다 이렇게 되면 점유 대기 조건이 깨지게 됩니다.
즉, 이미 가진 자원을 계속 쥐고 있으면서 다른 자원을 기다리기 때문에 데드락이 발생할 수 있는 환경이 만들어집니다.

3. 비선점 (No Preemption)

비선점(No Preemption)은 이미 점유된 자원을 강제로 빼앗을 수 없다는 특징을 의미합니다.
다시 식사하는 철학자 문제를 예로 들어보겠습니다.
철학자가 포크를 하나 집었다면, 다른 철학자가 그 포크를 강제로 빼앗을 수 없습니다.
즉, 포크를 집은 철학자가 스스로 내려놓기 전까지는 다른 철학자가 사용할 수 없습니다.
이처럼 자원을 강제로 회수할 수 없다면, 자원을 기다리는 상황이 더 쉽게 만들어질 수 있습니다.

4. 순환 대기 (Circular Wait)

순환 대기(Circular Wait)는 여러 작업들이 서로의 자원을 기다리는 순환 구조가 만들어지는 상황을 의미합니다.
예를 들어 다음과 같은 상황을 생각해 볼 수 있습니다.

철학자 A → 철학자 B의 포크 대기
철학자 B → 철학자 C의 포크 대기
철학자 C → 철학자 D의 포크 대기
철학자 D → 철학자 A의 포크 대기

이처럼 서로가 서로의 자원을 기다리는 순환 구조가 만들어지면 어느 누구도 작업을 진행할 수 없게 됩니다.
이 상태가 바로 데드락입니다.


이렇게 4가지 원인.. 아니고 특징에 대해 작성해봤는데 어찌보면 당연한느낌이라고 인거 같습니다. 즉, 4가지가 충족이되어지면, 데드락이 발생하는 것이 아니라 데드락이 발생이 되어지면 4가지의 조건이 있다고 여겨집니다.

라이브락 (Livelock)

역시 어원을 먼저 생각해봅시다.

Livelock = Live + Lock

  • Live : 살아있는, 계속 움직이는
  • Lock : 잠금

직역해 보면 살아있는 락이라는 의미입니다.
이 말은 조금 이상하게 들릴 수도 있습니다. 왜냐하면 락이 걸렸다면 보통 멈춰 있다고 생각하기 때문입니다.
하지만 라이브락은 조금 다른 특징을 가지고 있습니다.
스레드나 작업이 멈춰 있는 것은 아니지만, 서로의 행동 때문에 작업이 계속 진행되지 않는 상태입니다.

어떻게 보면, 데드락과 정반대의 길을 걷는다고 할 수 있습니다. 이것은 반은 맞고 반은 틀린 표현이라고 생각합니다.
혹자는, 데드락의 반대고 점유의 반대가 양보니까 그 둘을 반대로 생각하는 경우도 있을거라고 생각합니다.
하지만, 실제로는 그렇지 않습니다.

다시, 식사하는 철학자 문제로 돌아가봅시다.

만약, 데드락이 아닌 라이브 락이 걸린 상황이라면 어떨까요?
위 특징에 대입을 해봅시다.

다시 철학자 5명이서 식사를 하고 있습니다. 역시나 양쪽에 포크를 들어야 식사가 가능했습니다.
이전에는 철학자끼리 자신이 먼저 식사를 하려고 하다가 음식이 상한 경험이 있는지 이번에는 서로 양보하기 시작했습니다.

출처: 나무위키
여기서 주목해야 하는 점은 점유를 하려 포크를 봤을때, 이미 사용중이라면, 데드락인 경우에는 기다렸습니다.
하지만 양보는 다릅니다.
 

양보의 가장 큰 특징은 가만히 앉아서 양보가 불가능하다는 점입니다. 

양보는 움직여야 합니다. 아니면 말로 식사를 먼저 권유를 해야겠죠?
하지만 모든 철학자가 배려심이 넘쳐서 양보를 계속한다고 해봅시다. 

먼저 드세요 먼저 드세요.... 철학자들은 계속 움직이고 양보할겁니다.
하지만 음식은 아무도 먹지 않는 기이한 현상이 발생이 되는 거죠. 이것이 라이브락입니다.

결론

식사하는 철학자 문제를 통해 데드락과 라이브락에 대해 살펴보았습니다. 데드락은 서로 자원을 기다리면서 아무도 움직이지 못하는 상태이고, 라이브락은 서로 양보하려다 계속 움직이지만 작업이 진행되지 않는 상태입니다. 여기서 기억해야 할 점은 양보를 하려면 움직여야 한다는 점입니다. 움직이지 않으면 양보할 수도 없기 때문에, 결국 아무것도 진행되지 않는 데드락 상태가 됩니다. 반대로 계속 움직이며 서로를 피하려다 보면 라이브락이 발생할 수 있습니다. 결국 두 문제는 방식은 다르지만, 시스템의 진행을 막는다는 점에서는 같은 문제라고 볼 수 있습니다.

반응형

'개발' 카테고리의 다른 글

Stateless하게 개발하기  (0) 2026.03.19
스프링 이벤트 리뉴얼(1) - Publisher  (0) 2026.03.18
문제 발견: LazyConnectionDataSourceProxy 톺아보기  (1) 2026.03.13
Actuator 메트릭 생성 하기  (0) 2026.03.11
Actuator  (0) 2026.03.11

댓글

Designed by JB FACTORY