매우 오랜 시간이 걸릴 것으로 예상되는 작업이 있고 최대 스레드 수에 도달 할 때까지 ScheduledThreadPoolExecutor이 실행해야하는 다른 작업에 대한 추가 스레드를 생성한다고 생각할 수 있습니다.ScheduledThreadPoolExecutor가 고정 된 수의 스레드 만 수락하는 이유는 무엇입니까?
하지만 풀에 고정 된 수의 스레드 만 지정할 수있는 것 같습니다. 그 이유는 무엇입니까?
왜, 나도 몰라. 그러나 나는 상상할 수있다.
컴퓨터의 리소스 양이 제한되어 있습니다. 모든 자원을 동시에 처리 할 수있는 것은 아닙니다.
여러 프로세스가 동시에 파일을로드하는 경우 순차적으로로드되는 것보다로드 속도가 느립니다 (적어도 하드 디스크에있는 경우).
또한 프로세서는 여러 스레드를 동시에 처리하는 데 대한 지원이 제한되어 있습니다. 어떤 시점에서 OS 또는 JVM은 스레드가 코드를 실행하는 데 소비하는 시간보다 스레드를 전환하는 데 더 많은 시간을 소비합니다.
ScheduledThreadPoolExecutor이 그런 식으로 설계되어야하는 좋은 이유입니다. 임의의 양의 작업을 대기열에 넣을 수 있지만 효율적으로 실행할 수있는 것보다 더 많은 작업을 동시에 실행하지 않습니다. 물론 균형을 유지하는 것은 당신에게 달려 있습니다.
작업이 IO 바운드 인 경우 풀 크기를 작게 설정하고 CPU 바인딩 된 경우 조금 더 크게 설정합니다 (32 정도). 또한 IO 연결 작업과 CPU 연결 작업에 대해 하나씩 여러 개의 ScheduledThreadPoolExecutor을 만들 수 있습니다.
SchecduledThreadPoolExecutor에 대한 자세한 내용은 link입니다.이 링크에서는 SchecduledThreadPoolExecutor가 Timer 클래스의 많은 문제를 해결한다고 설명합니다. 그리고 SchecduledThreadPoolExecutor를 도입 한 이유는 Timer (Timer의 다양한 문제로 인해)를 대체하기위한 것이 었습니다. SchecduledThreadPoolExecutor에 전달 된 고정 된 수의 스레드에 대한 이유가이 클래스가 해결하는 문제 중 하나라고 생각합니다. 즉
스레드는 하나만 시작됩니다. 작업 당 스레드를 만드는 것보다 이 더 효율적이지만 최적 솔루션은 입니다. 최적의 솔루션은 모든 작업에 대해 하나의 스레드와 작업 당 하나의 스레드 사이에 여러 개의 스레드를 사용할 수 있습니다. 효과에서 가장 좋은 해결책은 스레드 풀에 작업을 배치하는 것입니다. 풀의 풀 수는 이어야하며 풀에서 최적 스레드 수를 확인할 수 있도록 으로 지정해야합니다.
제 의견으로는 여기가 SchecduledThreadPoolExecutor의 유스 케이스입니다. 귀하의 경우, 계획 할 작업과 이러한 작업이 완료되는 데 걸리는 시간에 따라 최적의 가치를 결정할 수 있어야합니다. 만약 내가 같은 시간 동안 다른 작업을 실행하는 경우 4보다 큰 내 수영장 크기를 선호하는 동일한 시간에 예정된 4 장기 실행 작업이 있습니다. 또한 이전 답변에 표시된 것처럼 다른 집행자에서 장기 실행 작업을 분리하는 것을 선호합니다.
희망이 Java Concurrency In Practice에 따르면 :) 도움이
바운드 형식의 thread 창조의 다음과 같은 단점이 있습니다 :
가스레드 생명주기 오버 헤드
스레드 생성과 분해가 무료로하지 않습니다가. 스레드 작성에는 시간이 필요하며 JVM 및 OS에 의한 일부 처리 활동이 필요합니다.
자원 소비
활성 스레드, 특히 메모리 시스템 리소스를 소모합니다. 사용 가능한 프로세서보다 실행 가능한 스레드가 많으면 스레드가 유휴 상태입니다. 유휴 쓰레드가 많으면 가비지 컬렉터에 많은 압박을 가할 수 있고 CPU를 경쟁하는 많은 쓰레드가 다른 성능 비용을 부과 할 수 있습니다. 모든 CPU를 사용하기에 충분한 스레드가 있으면 더 많은 스레드를 작성하는 것이 도움이되지 않으며 아플 수 있습니다.
안정성
만들 수 있습니다 얼마나 많은 스레드에 제한이 있습니다. 이 제한은 플랫폼에 따라 다르며 JVM 호출 매개 변수, 스레드 생성자의 요청 된 스택 크기 및 기본 운영 체제에 의해 배치 된 스레드의 제한을 포함하는 요소의 영향을받습니다. htis 한도에 도달하면 가장 가능성있는 결과는 OutOfMemoryError입니다. 이러한 오류를 복구하려고 시도하는 것은 매우 위험합니다. 이 제한을 피하지 않도록 프로그램을 구조화하는 것이 훨씬 쉽습니다.
무제한 스레드 작성은 프로토 타입 작성 및 개발 중에 제대로 작동하는 것처럼 보일 수 있으며 응용 프로그램을 배포하고 부하가 많은 경우에만 문제가 발생합니다.