문제

새 스레드를 사용하는 것과 스레드 풀에서 스레드를 사용하는 것의 차이점은 무엇입니까? 어떤 성능 이점이 있으며 왜 명시 적으로 만든 것보다 수영장에서 스레드를 사용하는 것을 고려해야합니까? 나는 여기에서 .net에 대해 구체적으로 생각하고 있지만 일반적인 예는 괜찮습니다.

도움이 되었습니까?

해결책

스레드 풀은

  • 새 스레드를 만드는 대신 이미 생성 된 스레드 재사용 (비싼 프로세스)

  • 새로운 작업 항목에 대한 요청이 파열 될 때 스레드 생성 속도를 조절합니다 (이것은 .NET 3.5에만 있다고 생각합니다)

    • 100 스레드 풀 작업을 대기하는 경우 이러한 요청을 서비스하기 위해 이미 작성된만큼의 스레드 만 사용합니다 (예 : 10). 스레드 풀은 자주 확인할 것입니다 (3.5 SP1의 500ms마다 믿습니다). 대기하는 작업이 있으면 하나의 새로운 스레드가 만들어집니다. 작업이 빠르면 새 스레드의 수가 작아지고 짧은 작업을위한 10 개 정도의 스레드를 재사용하는 것이 100 개의 스레드를 전선하는 것보다 빠릅니다.

    • 워크로드가 지속적으로 많은 수의 스레드 풀 요청이있는 경우, 스레드 풀이 위의 프로세스를 통해 풀에 더 많은 스레드를 생성하여 스레드 풀이 워크로드에 자체적으로 조정하여 요청을 처리 할 수있는 더 많은 스레드가 있습니다.

    • 확인하다 여기 스레드 풀이 후드 아래에서 어떻게 작동하는지에 대한 자세한 정보

작업이 비교적 오래 달리면 새로운 스레드를 직접 만들어 낼 수 있습니다 (아마도 1 ~ 2 초 정도이지만 특정 상황에 따라 다릅니다)

@krzysztof- 스레드 풀 스레드는 메인 스레드가 끝날 때 중지되는 배경 스레드입니다. 수동으로 생성 된 스레드는 기본적으로 전경이되지만 (기본 스레드가 종료 된 후에도 계속 실행됩니다) 시작을 호출하기 전에 배경으로 설정할 수 있습니다.

다른 팁

.NET Managed ThreadPool : -

  • 현재 워크로드 및 사용 가능한 하드웨어를 기반으로 한 크기 자체
  • 작업자 스레드가 포함되어 있습니다 그리고 완료 포트 스레드 (IO 서비스에 특별히 사용되는)
  • 상대적으로 짧은 수명이 많은 운영에 최적화됩니다.

장기 실행 작업에 더 적합한 다른 스레드 풀 구현이 존재합니다.

구체적으로 스레드 풀을 사용하여 앱이 생성되지 않도록합니다. 너무 많아 스레드. ThreadPool의 가장 중요한 기능은 작업 대기열입니다. 즉, 컴퓨터가 충분히 바쁘게되면 ThreadPool은 더 많은 스레드를 즉시 스폰하지 않고 요청을 대기합니다.

따라서 작고 경계가 작은 스레드를 만들면 스스로 직접 만듭니다. 앞면의 스레드 수를 결정할 수없는 경우 (예 : 들어오는 IO에 대한 응답으로 생성 된 스레드) 및 해당 작업이 수명이 짧은 경우 ThreadPool을 사용하십시오. 얼마나 많은지 모르지만 그들의 작업이 장기적으로 운영 될 것인지, 플랫폼에 도움이되는 것은 없지만 대체 스레드 풀 구현을 찾을 수있을 것입니다.

또한

new Thread().Start()

프로그램을 닫으면 죽지 않는 전경 스레드를 스폰합니다. ThreadPool 스레드는 앱을 닫을 때 죽는 배경 스레드입니다.

나는 이들에 대한 상대적 자원 사용에 대한 호기심을 가지고 있었고 Windows 8의 .NET 4.0 릴리스 빌드를 사용하여 2012 듀얼 코어 인텔 i5 랩톱에서 벤치 마크를 실행했습니다. 스레드 풀은 평균 5.06을 차지하는 데 평균 0.035ms를 걸었습니다. MS. 다시 말해서 수영장의 실은 많은 수의 짧은 수명에 대해 약 300 배 빠르게 시작되었습니다. 적어도 테스트 된 범위 (100-2000) 스레드에서 스레드 당 총 시간은 상당히 일정하게 보였습니다.

이것은 벤치마킹 된 코드입니다.

    for (int i = 0; i < ThreadCount; i++) {
        Task.Run(() => { });
    }

    for (int i = 0; i < ThreadCount; i++) {
        var t = new Thread(() => { });
        t.Start();
    }

enter image description here

이전 스레드를 여기에서 확인하십시오.

.NET에서 스레드 풀을 언제 사용하지 않아야합니까?

요약은 많은 짧은 스레드를 생성 해야하는 경우 ThreadPool이 좋습니다. 반면 스레드를 사용하면 좀 더 제어 할 수 있습니다.

스레드 로컬 스토리지는 스레드 풀에서는 좋은 아이디어가 아닙니다. 스레드에게 "ID"를 제공합니다. 모든 스레드가 더 이상 동일하지는 않습니다. 이제 스레드 풀은 동일한 스레드가 필요한 경우 특히 유용하며, 창조 오버 헤드없이 작업을 수행 할 준비가되어 있습니다.

많은 스레드가 필요한 경우 ThreadPool을 사용하고 싶을 것입니다. 스레드 생성의 오버 헤드를 절약하는 스레드를 재사용합니다.

무언가를 끝내기 위해 하나의 스레드 만 있으면 스레드가 가장 쉬울 것입니다.

Theadpool 스레드의 주요 요구는 거의 즉시 완료 될 것으로 예상되는 짧은 작은 작업을 처리하는 것입니다. 하드웨어 인터럽트 핸들러는 종종 커널이 아닌 코드에 적합하지 않은 스택 컨텍스트에서 실행되지만 하드웨어 인터럽트 핸들러는 사용자 모드 I/O 완료 콜백이 가능한 빨리 실행되어야한다는 것을 발견 할 수 있습니다. 그러한 것을 실행하기 위해 새로운 스레드를 만드는 것은 방대한 과잉 일 것입니다. I/O 완료 콜백 또는 기타 유사한 것들을 실행하기 위해 발송할 수있는 사전 제작 된 스레드가 몇 개 있으면 훨씬 더 효율적입니다.

이러한 스레드의 주요 측면은 I/O 완료 방법이 항상 본질적으로 즉시 완료되고 차단되지 않는 경우 현재 그러한 메소드를 실행하고있는 그러한 스레드의 수는 최소한 프로세서 수와 동일하다는 것입니다. 위에서 언급 한 방법 중 하나가 다른 방법 중 하나가 블록 또는 실행 시간이 일반 스레딩 시간 슬라이스를 초과하는 경우에 실행될 수 있습니다. 스레드 풀이 의도 한대로 사용되면 그 중 어느 것도 자주 발생하지 않아야합니다.

방법이 실행을 시작할 때 100ms 이내에 종료 될 것으로 예상 될 수없는 경우, 메인 스레드 풀 이외의 일부 수단을 통해 메소드를 실행해야합니다. CPU 집중적이지만 차단하지 않는 수행해야 할 작업이 많으면 사용한 이후 "기본"스레드 풀과 별개의 응용 프로그램 스레드 풀 (CPU 코어 당 하나)을 사용하여 발송하는 것이 도움이 될 수 있습니다. 비 차단 CPU 집약적 인 작업을 실행할 때 코어보다 더 많은 스레드가 비생산적입니다. 그러나 메소드가 실행하는 데 1 초 이상 걸리고 대부분의 시간이 차단되면이 방법은 전용 스레드에서 실행되어야하며 메인 스레드 풀 스레드에서 실행되지 않아야합니다. I/O 콜백과 같은 장기 실행 작업을 트리거 해야하는 경우 콜백 전에 장기 실행 작업을위한 스레드를 시작하고 콜백이 펄스가 펄럭 거리는 모니터에서 기다려야합니다. 콜백이 종료되는 동안 콜백에 새 스레드를 시작하여 콜백이 종료되어 자체 스레드를 스레드 풀로 효과적으로 반환하십시오.

일반적으로 (.NET을 사용한 적이 없음) 스레드 풀은 자원 관리 목적으로 사용됩니다. 제약 조건을 소프트웨어로 구성 할 수 있습니다. 새로운 스레드의 생성이 비용이 많이 들기 때문에 성능의 이유로 수행 될 수도 있습니다.

시스템 구체적인 이유도있을 수 있습니다. Java에서 (다시 .NET에 적용되는지 모르겠습니다), 스레드의 관리자는 각 스레드가 풀에서 가져 오면 스레드 특정 변수를 적용하고 반환 될 때 설정하지 않을 수 있습니다 (같은 것을 통과하는 일반적인 방법 신원).

예제 구속 조건 : 10 DB 연결 만 있으므로 데이터베이스에 액세스하기 위해 10 개의 작업자 스레드 만 허용합니다.

그렇다고해서 자신의 스레드를 만들어서는 안된다는 의미는 아니지만 수영장을 사용하는 것이 합리적 인 조건이 있습니다.

수영장을 사용하는 것은 좋은 생각입니다. 얼마나 많은 스레드를 생성 할 것인지 모르거나 제어 할 수없는 경우 좋은 생각입니다.

스레드를 사용하여 양식에 문제가있어서 목록 컨트롤의 위치 변경 이벤트의 데이터베이스에서 일부 필드를 업데이트하십시오 (freez 피피). 사용자가 목록 위치를 너무 빨리 변경하고 있었기 때문에 사용자가 데이터베이스에서 오류가 발생하는 데 5 분이 걸렸습니다 (액세스가 너무 많음).

기본 문제를 해결하는 다른 방법이 있다는 것을 알고 있습니다 (액세스 사용을 포함하지 않음). 풀링은 좋은 시작입니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top