try-catch-finally를 사용해서 finally { notify() } 를 하지 않는 이유?

Question

예제 3번 코드를 보다 의문이 들어 질문드립니다. 코드를 보면, @Override public synchronized void put(String data) { // 버퍼가 가득 찬 경우, 빌 때까지 주기적으로 체크 while (queue.size() == max) { log("[put] 큐가 가득 참, 생산자 대기"); try { wait(); log("[put] 생산자 깨어남"); } catch (InterruptedException e) { throw new RuntimeException(e); } } queue.offer(data); log("[put] 생산자 데이터 저장, notify() 호출"); notify(); // WAIT -> BLOCKED } 에서 인터럽트 예외가 발생하면 밑의 notify() 코드가 호출이 되지 않습니다. 이 문제 상황에서 한 스레드라도 notify()문을 호출하지 않게되면 영원히 대기 중인 스레드가 생겨서 정상적인 프로그램 종료가 일어나지 않을 것 같습니다. 그래서 제 생각은 notify() 메서드를 finally문으로 감싸줘야 한다고 생각하는데 이게 맞는지 궁금합니다.

인프런 AI 인턴 · Answer

안녕하세요, 인프런 AI 인턴입니다. 천권욱님. 생산자-소비자 패턴에서 notify() 를 finally 블록에 넣는 것이 맞는지에 대한 질문을 주셨습니다. 이 부분에 대해 설명드리겠습니다. 문제의 핵심 코드에서 wait() 메소드 호출 중에 InterruptedException 이 발생하면 notify() 호출이 되지 않는 상황을 염려하고 계십니다. 이로 인해 대기 중인 스레드가 영원히 깨어나지 못할 수 있다는 우려입니다. notify()의 위치 notify() 를 finally 블록에 넣어야 한다고 생각할 수 있습니다. 이유는 예외가 발생하더라도 finally 블록의 코드는 항상 실행되기 때문입니다. 하지만 notify() 를 무조건적으로 finally 블록에 넣는 것은 권장되지 않습니다. 이유는 notify() 는 조건이 충족될 때에만 호출되어야 합니다. 그렇지 않으면 다른 대기 중인 스레드들이 불필요하게 깨어나게 됩니다. 예를 들어, 아직 조건이 충족되지 않았는데 notify() 를 호출하면 소비자 스레드에게 올바르지 않은 상태를 전달하게 되며, 이는 프로그램의 논리적 오류를 유발할 수 있습니다. 올바른 구현 방안 InterruptedException 이 발생하면 다시 while (queue.size() == max) 조건을 재검토하고 적절히 대기 상태로 들어가는 것이 좋습니다. 예외 발생 시 적절하게 복구 로직을 구성하는 것이 필요합니다. 이를 통해 프로그램이 올바른 로직에 따라 진행되도록 해야 합니다. 기존 답변 링크 스레드 상태 및 인터럽트에 대해 자세히 알아보기 : 여기에서는 스레드 간의 인터럽션 관리 및 상태 제어에 대해 설명하고 있습니다. 저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.