Java 가비지 수집 스레드 우선 순위

Question

인터뷰에서 다음 질문을 받았습니다. "가비지 수집 스레드의 기본 우선 순위는 무엇입니까?" 기본 우선 순위에 대해 들어 본 적이 없지만 GC를 강제 적용하거나 우선 순위를 변경할 수는 없습니다. 아는 사람 있나요?

Answer 1

아마 인터뷰 담당자가 찾고있는 대답은 GC가 우선 순위가 낮은 백그라운드 프로세스에 있다는 것입니다. 그 이유는 GC를 실행하는 것이 비용이 많이 들지만 중요한 프로세스가 아니기 때문에 중요한 작업을 방해하지 않고 시스템이 처리 할 시간이있을 때만 수행해야합니다. (실시간 시스템에는 유사한 개념이 존재한다. 백그라운드 작업에서 중요하지 않은 프로세스와 포 그라운드에서 중요한 모든 프로세스가 백그라운드 작업보다 우선 순위가 높다.)

당신은 가비지 콜렉션에 대한 Sun 문학을 읽었을 뿐이고 GC를 우선 순위가 낮은 스레드로 실행하는 것은 이 아닙니다. 바로입니다. 실제로 GC는 단일 스레드가 아닐 수도 있습니다. 대신 GC는 메모리가 부족할 때 실행됩니다 (메모리가 부족할 때를 결정하는 것은 백그라운드 스레드에서 수행됩니다. 아마도 다른 사람이이를 명확히 할 수 있습니다). 여기

는 GC에 읽는 좋은 링크입니다 :

• http://www.javacoffeebreak.com/articles/thinkinginjava/abitaboutgarbagecollection.html
• Is it possible to change the priority of garbage Collector thread?

Answer 2

그것은 (정확한 우선 순위에 대해 확실하지) 낮은 우선 순위 스레드입니다. 여기에서 핵심은 가능한 경우 GC가 일반 스레드를 느리게하는 것을 피하는 것입니다. 나는 그것이 보통 우선 순위보다 낮다고 말할 것이다.

Answer 3

질문은 JVM의 실제 구현을 목표로했을지도 모른다. 온라인 참조에서 읽을 수 있듯이 가비지 수집기를 구현하는 여러 가지 방법이 있으며 버전마다 다를 수 있습니다. 그래서 모든 사람들이 GC의 동작에 의존하지 말라고 알려줍니다. 그것은 다른 JVM에서 다르게 작동합니다.

Answer 4

적어도 Java RTS에서는 필요에 따라 가비지 수집 스레드의 우선 순위를 조정할 수 있습니다. 우선 순위 조정 (및 일반적으로 쓰레드 스케줄링)은 하나 이상의 CPU보다 여러 CPU에서 다소 다릅니다.

지금까지 더 이상 공통적 인 것이 아니기 때문에 다중 CPU 구성을 가정하겠습니다. 또한 기본 스케줄러에 대해서만 말하고 있습니다. 다른 스케줄러는 완전히 다른 방식으로 작업을 수행 할 수 있습니다. 스레드는 기본적으로 중요 및 비 중요 우선 순위의 두 클래스로 분류됩니다 (둘 중 하나보다 높은 "힙이없는 실시간"스레드를 가질 수도 있지만 힙을 사용할 수 없기 때문에 GC와의 관련성이 적음). 가비지 콜렉션 스레드는 일반적으로 이들 중 하나보다 낮은 우선 순위로 실행되지만, 은이 필요한 경우 중요하지 않은 스레드보다 높은 우선 순위로 부스트 될 수 있습니다. GC 스레드 우선 순위는 항상 중요한 실시간 스레드보다 낮습니다.

저는 "중요한"우선 순위와 "중요하지 않은"우선 순위 사이의 구분에 대해 약간 모호했습니다. 그 이유는 조정이 가능하기 때문입니다. GC가 선점 할 수있는 우선 순위와 선택할 수없는 우선 순위를 선택할 수 있습니다. 중요한 스레드는 하드 실시간 응답을 얻고, 중요하지 않은 스레드는 소프트 실시간 응답을 얻습니다. 어떤 쓰레드가 어떤 카테고리에 속하는지 결정/결정하는 것은 당신에게 달려 있습니다.

Answer 5

이 질문에 대한 정답은 "가비지 수집기의 스레드 우선 순위에 대해 걱정할 필요가 있다고 생각하면 아마도 잘못된 것을하고있는 것입니다."라고 말하고 싶습니다.

스레드 우선 순위는 프로세스가 얼마나 많은 CPU 시간을 가져야하는지 직접적으로 관련이있는 것은 아닙니다. 시스템에 따라 다르지만 Windows에서는 스레드 우선 순위가 기본적으로 실행 대기중인 스레드가 사용 가능한 CPU에 예약되어있는 ORDER를 결정하는 데 사용되므로 우선 순위가 높은 스레드가 우선 순위가 낮은 스레드를 우선 처리 할 수 ​​있습니다 두 스레드가 실제로 CPU를 놓고 경쟁하고 있다고 가정합니다. "우선 순위가 낮은 CPU에 CPU 시간을 줄"는 것은 실제 규칙이 아닙니다. (리눅스에서는 스레드 우선 순위 (좋은 값)과 할당 된 CPU 시간 사이에 직접적인 관계가 있습니다.)

스레드 우선 순위가 Windows에서와 같이 사용되면 백그라운드 스레드로 사용됩니다 가비지 컬렉터처럼 더 적절한 해결책은 아마도 역설적이게도 높은 우선 순위를 부여한 다음 다른 방법으로 CPU 사용 비율을 제어하는 ​​것입니다 (기본적으로 적절한 시간 동안 적절한 시간 동안 자거나 적절한 신호를 기다리는 중입니다) . 특히 높은 우선 순위는 대부분의 시간을 수행 할 필요가없는 백그라운드 스레드에 적합하지만 어떤 작업을 수행해야 할 경우 가능한 한 빨리 수행해야합니다.

특정 가비지 수집 알고리즘에 의해 어떤 스레드 우선 순위가 사용되는지는 실제로 보지 못했습니다. 그러나 요점은 상황이 다소 복잡하고 스레드 우선 순위에서 가비지 수집기의 동작에 대한 가정을 근거로 이상하게 보입니다.

스레드 우선 순위에 더 많은 관심이있는 사람들은 내가 취한 measurements of the effect of thread priorities을 보길 원할 것입니다. 2 년 전에는이 자료가 업데이트 될 수있었습니다.

업데이트 : 우연히, talk by Cliff Click이 어제 YouTube에 게시되었습니다. 약 35 분 동안 그는 JIT와 GC 스레드가 굶어 죽지 않도록 우선 순위를 매길 필요가 있다는 점을 정확하게 언급했습니다.