자바 스레드 수면 해결 및 동기화 된 블록을 기다리는 중

Question

스레드 수면 해결 방법과 sleep()의 단순한 해결 방법에 대해 자세히 알고 싶습니다.

나는 그것의 운영 체제에 의해 정의 된 알고 Windows에서 일반적으로 15ms. 나는이 문제를 최근에 조사하여 확인할 수는 없었지만, 15ms가 OS에 의해 반복되고 모든 스레드에 대해 '전역'이라는 것을 모호하게 상기합니다. 즉, 스레드가 잠자기 할 수있는 최소 시간 인 15ms가 아니라 오히려 최대 수면 (1). 그게 맞습니까? 모든 운영 체제에서 동일합니까 (기간 초과)?

이 문제가 발생할 수있는 상황을 생각할 수 없지만 스레드의 가짜 깨우기가 항상이 수면주기의 동작 지점에서 발생합니까, 아니면 언제든지 발생할 수 있습니까?

동기화 된 블록에서 대기중인 스레드가 효과적으로 잠을 자며 (1) 각주기마다 잠금을 확인합니까? 아니면 블록을 종료 한 스레드가 대기중인 스레드를 즉시 깨 웁니까? 모든 운영 체제에서 동일합니까?

스레드가 wait() 후 알림() 될 때, 잠금을 기다리는 동안 또는 위와 같은 방식으로 처리됩니까?

15ms 루프가 성능 관점에서 관련성이있는 다른 시간이 있습니까?

Answer 1

멀티 스레드 커널에 대한 약간의 연구가 필요합니다.

'스레드의 가짜 웨이크 업은 항상이 수면 사이클의 동작 지점에서 발생합니까, 아니면 언제든지 발생할 수 있습니까?'

sleep() 또는 Windows에서 모든 커널 싱크 개체 대기와 관련된 허위 웨이크 업이 전혀 없습니다. 전혀 발생하지 않습니다. 이러한 경향은 커널에서 없어져서 사용자 스레드에 전파되지 않습니다.

스레드가 뮤텍스 또는 세마포 잠금과 같은 일부 동기화 개체를 대기 또는 대기중인 경우 스레드가 전혀 실행되지 않습니다. 커널의 큐에있는 단지 죽은 '스레드 설명자 개체' 관련 자료, 스택을위한 데이터 공간 등. 잠자기의 경우 TDO는 웨이크 업 시간순으로 정렬 된 모든 시간 초과 스레드의 '델타 큐'에 있으며 OS는이 대기열의 헤드에서 항목을 매번 확인합니다 15ms. 시간 초과 잠금 대기의 경우 TDO는 두 개의 대기열, 즉 시간 초과 대기열과 잠금이 소유 한 대기열에 있습니다. TDO가 타이머 대기열의 헤드에 도달하여 간격이 올라간 경우 준비가 완료되거나 다른 스레드가 잠금을 해제하고 스레드를 준비시킵니다. 어느 것이 먼저 도착하면 승리하고 TDO는 다른 대기열에서 제거됩니다. 새롭게 준비된 스레드는 준비된 스레드 세트에 조인하고, 코어가 사용 가능하거나 우선 순위가 낮은 스레드를 선점 할 수 있으면 새로 준비된 스레드가 코어에 디스패치됩니다.

Windows에서 '15ms'는 모든 스레드가 '공유'합니다. Windows는 데스크톱 OS이며 15ms는 직접적인 인간의 감각을 초월합니다. 따라서 모든 가사 스레드의 99.9 %는 큰 시간 초과가 필요하거나 I/O를 기다리고 있거나 일부 스레드 간 통신 잠금 또는 일부 조합을 기다리고 있기 때문에 걱정하지 않습니다. 그것의.

'15ms 루프가 성능 관점에서 관련성이있는 다른 시간이 있습니까?'

별로 많지 않습니다. 가장 높은 우선 순위의 실행 가능 스레드 세트가 실행 가능한 코어 수보다 클 경우 세트가 라운드 로빈 방식으로 실행된다는 점에서 타이머 일정 조정의 부작용이 있습니다. 그 이유는 해당 스레드 목록 둥근 회전합니다. 이는 정기적으로 오버로드 된 시스템에만 관련되며 대부분의 스레드는 타이머 간격을 사용하여 다른 차단 시스템 호출을 시간 종료합니다.

Answer 2

Thread.sleep() 구현은 OS에 따라 다릅니다.

슬립의 세분성은 일반적으로 스레드 스케줄러의 인터럽트 기간에 의해 제한됩니다. 리눅스에서는이 인터럽트주기가 일반적으로 최근 커널 (2.6.8 이후)에서 1ms입니다. Windows에서 스케줄러의 인터럽트주기는 대개 10 또는 15 밀리 초 (프로세서에 의해 결정된다고 생각합니다)이지만, 소프트웨어에서 더 높은 기간을 요청할 수 있으며 핫스팟 JVM은 필요하다고 판단 될 때 그렇게합니다.