스레드가 인터럽트에 응답하여 객체 잠금을 기다리지 않는 이유는 무엇입니까? 나는 약간 수색을하고 interuppting blocked thread를 읽었다. java와 같은 인수를 이해합니다. 메서드 만 예외를 throw해야하며 동기화 된 블록은 예외를 throw 할 수 없습니다. 그러나 이런 종류의 대기 잠금 동작은 교착 상태의 원인이 확실합니다 ( ). 왜 cant 언어 스팩을 사용하면 동기화 된 블록이 인터럽트 된 예외를 던져서 개발자가 처리하도록 만들까요? 어떤 이유가 있어도 언어 사양이 현명하지 못한 이유가 무엇입니까? 또한 대답은 인터럽트가 스레드를 중지/취소하는 것이 아니라고 말합니다. 그렇다면 Lock.lockInterruptibly()가 나중에 도입 된 이유는 무엇입니까?인터럽트에 대한 응답으로 객체 잠금을 기다리는 스레드가 아닌 이유는 무엇입니까?
synchronized 키워드의 전체적인 점은 간단해야합니다 (또는 적어도 멀티 스레딩이 가능한 한 간단합니다). 이것은 오라클의 Java tutorial on Lock objects에서 명시 적으로 언급되었습니다.
동기화 코드는 간단한 종류의 재진입 잠금에 의존합니다. 이 잠금 장치는 사용하기 쉽지만 많은 제한이 있습니다. 더 복잡한 잠금 관용구는
java.util.concurrent.locks패키지에서 지원됩니다.
대기중인 스레드를 중단시키는 기능이 부족합니다.
기본적으로 설계 원칙은 가장 간단한 형태의 상호 배제가 필요한 경우 synchronized이 좋습니다. 최소 이상의 것을 필요로한다면 다른보다 정교한 도구 중 하나를 사용해야합니다.
... 그리고이 때문에 몇몇 필드를 업데이트하는 데 걸리는 시간보다 더 오랫동안 'synchronized'잠금을 유지하지 못하도록 코드를 설계해야합니다. –
답변에 동의합니다. 나는 그 행동에 대해 혼란스럽지 않다. 내가 이해하지 못했던 것은 "이 영원한 try-to-lock"동작으로 인해 교착 상태가 쉽게 발생하고 복구가되지 않는 것 같았습니다. 타임 아웃과 인터럽트를 기다릴 수 없습니다. 교착 상태에 대한 명백한 원인이 있다면 언어 디자이너는 문제 해결 방법에 대해 생각해봤을 것입니다. 내가 생각할 수있는 한 가지 해결책은 인터럽트 (인터럽트가 스레드를 중지하는 최선의 방법이라고 가정)를 중단하는 것이 었습니다. 이전에 언어 디자인을 통해이 문제에 대한 해결책을 제시하지 않은 강력한 이유가 있는지 이해하고자했습니다. 아니면 내 가정이 잘못되었을 수 있습니다. – Thiru
우선, 여러 개의 잠금을 동시에 액세스하는 경우에만 교착 상태가 발생할 수 있습니다. 그리고 언어 설계자는 앞서 말한보다 정교한 구조를 생각했습니다. 많은 경우 원하는 것은 원자 단위로 또는 일부 간단하게 필드를 설정하는 간단한 방법입니다. 그런 경우에는 필요한 것만 수행하는 쉬운 구성을 갖는 것이 좋습니다. – yshavit
관련 코드를 게시 할 수 있습니까? – Ali