FixedThreadPool 대 CachedThreadPool : 두 가지 악 중 적은 것

FixedThreadPool 대 CachedThreadPool : 두 가지 악 중 적은 것

---

여러 작업을 수행하는 스레드 (~ 5-150)를 생성하는 프로그램이 있습니다. 원래는 이 유사한 질문 이 더 오래 지속되는 작업에 더 적합하고 멀티 스레딩에 대한 매우 제한된 지식으로 인해 스레드의 평균 수명 (몇 분) " 장수 "를 고려 FixedThreadPool했기 때문에 a를 사용했습니다 .

그러나 최근에 추가 스레드를 생성하는 기능을 추가하여 설정 한 스레드 제한을 초과하게되었습니다. 이 경우 허용 할 수있는 스레드 수를 추측하고 늘리거나 CachedThreadPool낭비되는 스레드가 없도록 전환하는 것이 더 낫 습니까?

둘 다 미리 시도해 보면 별 차이 가없는 것 같아서CachedThreadPool 낭비를 피하기 위해 그냥 같이 가고 싶어요 . 그러나 스레드의 수명은 대신 a를 선택 FixedThreadPool하고 사용하지 않는 스레드를 처리 해야 함을 의미 합니까? 이 질문 은 여분의 스레드가 낭비되지 않는 것처럼 보이지만 설명에 감사드립니다.

---

CachedThreadPool은 장기 실행 스레드에 대해 사용하는 데 부정적인 결과가 없기 때문에 상황에 맞게 사용해야합니다. 짧은 작업에 적합한 CachedThreadPools에 대한 Java 문서의 주석은 단순히 이러한 경우에 특히 적합하다는 것을 암시하며, 장기 실행 작업과 관련된 작업에 사용할 수 없거나 사용해서는 안된다는 의미가 아닙니다.

더 자세히 설명하기 위해 Executors.newCachedThreadPool 및 Executors.newFixedThreadPool 은 모두 다른 매개 변수를 사용하는 동일한 스레드 풀 구현 (적어도 개방형 JDK에서)에 의해 지원됩니다. 차이점은 스레드 최소, 최대, 스레드 종료 시간 및 큐 유형입니다.

public static ExecutorService newFixedThreadPool(int nThreads) {
     return new ThreadPoolExecutor(nThreads, nThreads,
                                   0L, TimeUnit.MILLISECONDS,
                                   new LinkedBlockingQueue<Runnable>());
 }

public static ExecutorService newCachedThreadPool() {
    return new ThreadPoolExecutor(0, Integer.MAX_VALUE,
                                 60L, TimeUnit.SECONDS,
                                 new SynchronousQueue<Runnable>());
}

FixedThreadPool은 실제로 고정 된 수의 스레드로 작업하고 싶을 때 장점이 있습니다. 그런 다음 스레드 수가 지정된 수준으로 유지된다는 것을 알고있는 동안 실행 프로그램 서비스에 원하는 수의 작업을 제출할 수 있기 때문입니다. 스레드 수를 명시 적으로 늘리려면 이것은 적절한 선택이 아닙니다.

그러나 이것은 CachedThreadPool에서 발생할 수있는 한 가지 문제는 동시에 실행되는 스레드 수를 제한하는 것과 관련이 있음을 의미합니다. CachedThreadPool은이를 제한하지 않으므로 너무 많은 스레드를 실행하지 않도록 자체 코드를 작성해야 할 수 있습니다. 이것은 실제로 응용 프로그램의 디자인과 실행 프로그램 서비스에 작업을 제출하는 방법에 따라 다릅니다.

---

모두 FixedThreadPool와 CachedThreadPool고부하 애플리케이션에서 악이다.

CachedThreadPool 보다 위험하다 FixedThreadPool

애플리케이션이로드가 많고 낮은 지연 시간이 필요한 경우 아래의 단점으로 인해 두 옵션을 모두 제거하는 것이 좋습니다.

1. 작업 대기열의 제한없는 특성 : 메모리 부족 또는 긴 대기 시간이 발생할 수 있습니다.
2. 오래 실행되는 스레드는 CachedThreadPool스레드 생성에 대한 제어를 벗어납니다.

둘 다 악하다는 것을 알고 있기 때문에 덜 악은 선을 행하지 않습니다. 많은 매개 변수에 대한 세부적인 제어를 제공하는 ThreadPoolExecutor를 선호 합니다.

1. 더 나은 제어를 위해 작업 대기열을 제한된 대기열로 설정
2. 올바른 RejectionHandler-JDK에서 제공하는 자체 RejectionHandler 또는 기본 핸들러
3. 작업 완료 전후에 할 일이 있으면 무시 beforeExecute(Thread, Runnable)하고afterExecute(Runnable, Throwable)
4. 스레드 사용자 정의가 필요한 경우 ThreadFactory 재정의
5. 런타임에 동적으로 스레드 풀 크기 제어 (관련 SE 질문 : 동적 스레드 풀 )

---

그래서 많은 작업을 수행하는 스레드 (~ 5-150)를 생성하는 프로그램이 있습니다.

선택한 OS 및 하드웨어에서 스레드가 실제로 처리되는 방식을 이해하고 있습니까? Java가 스레드를 OS 스레드에 매핑하는 방법, 스레드를 CPU 스레드에 매핑하는 방법 등? ONE JRE에서 150 개의 스레드를 생성하는 것은 그 아래에 대규모 CPU 코어 / 스레드가있는 경우에만 의미가 있기 때문에 요청하는 것입니다. 사용중인 OS 및 RAM에 따라 n 개 이상의 스레드를 생성하면 OOM 오류로 인해 JRE가 종료 될 수도 있습니다. 따라서 스레드와 해당 스레드에서 수행 할 작업, 처리 할 수있는 작업 수 등을 실제로 구분해야합니다.

And that's the problem with CachedThreadPool: It doesn't make sense to queue up long running work in threads which actually can't run because you only have 2 CPU cores able to process those threads. If you end up with 150 scheduled threads you might create a lot of unnecessary overhead for the schedulers used within Java and the OS to concurrently process them. This is simply impossible if you only have 2 CPU cores, unless your threads are waiting for I/O or such all the time. But even in that case a lot of threads would create a lot of I/O...

And that problem doesn't occur with FixedThreadPool, created with e.g. 2+n threads, where n is reasonable low of course, because with that hardware and OS resources are used with far less overhead for managing threads which can't run anyway.

참고URL : https://stackoverflow.com/questions/17957382/fixedthreadpool-vs-cachedthreadpool-the-lesser-of-two-evils