Nota
O acceso a esta páxina require autorización. Pode tentar iniciar sesión ou modificar os directorios.
O acceso a esta páxina require autorización. Pode tentar modificar os directorios.
La System.Threading.ThreadPool clase proporciona a la aplicación un grupo de subprocesos de trabajo administrados por el sistema, lo que le permite concentrarse en tareas de aplicación en lugar de en la administración de subprocesos. Si tiene tareas cortas que requieran procesamiento en segundo plano, el grupo de subprocesos administrados permite aprovechar fácilmente las ventajas de varios subprocesos. El uso del pool de subprocesos es significativamente más sencillo en Framework 4 y versiones posteriores, ya que puede crear objetos Task y Task<TResult> que realizan tareas asincrónicas en hilos del pool de subprocesos.
.NET usa los subprocesos del grupo de subprocesos para muchos fines, incluidas operaciones de biblioteca TPL, la finalización de E/S asincrónica, las devoluciones de llamada del temporizador, las operaciones de espera registradas, las llamadas de métodos asincrónicos mediante delegados y las conexiones de socket System.Net.
Características del grupo de subprocesos
Los subprocesos del grupo de subprocesos son subprocesos en segundo plano. Cada subproceso usa el tamaño de pila predeterminado, se ejecuta con la prioridad predeterminada y se encuentra en el apartamento multiproceso. Una vez que un subproceso del grupo de subprocesos finaliza su tarea, se devuelve a una cola de subprocesos en espera. Desde este momento se puede reutilizar. Esta reutilización permite a las aplicaciones evitar el costo de crear un nuevo subproceso para cada tarea.
Hay solo un grupo de subprocesos por cada proceso.
Excepciones en los subprocesos del grupo de subprocesos
Las excepciones no controladas en los subprocesos del grupo de subprocesos finalizan el proceso. Existen tres excepciones a esta regla:
- Se genera un System.Threading.ThreadAbortException en un subproceso del grupo de subprocesos, porque se llamó a Thread.Abort.
- Se genera un System.AppDomainUnloadedException en un subproceso del grupo de subprocesos, porque se está descargando el dominio de aplicación.
- El entorno de ejecución de lenguaje común o un proceso anfitrión finaliza el hilo.
Para más información, consulte Excepciones en subprocesos administrados.
Número máximo de subprocesos del grupo de subprocesos
El número de operaciones que se pueden poner en cola en el grupo de subprocesos está limitado únicamente por la memoria disponible. Sin embargo, el grupo de subprocesos limita el número de subprocesos que pueden estar activos en el proceso simultáneamente. Si todos los subprocesos del grupo de subprocesos están ocupados, los elementos de trabajo adicionales se pondrán en cola hasta que estén disponibles subprocesos para ejecutarlos. El tamaño predeterminado del grupo de subprocesos de un proceso depende de varios factores, como el tamaño del espacio de direcciones virtual. Un proceso puede llamar al ThreadPool.GetMaxThreads método para determinar el número de subprocesos.
Puede controlar el número máximo de subprocesos mediante los métodos ThreadPool.GetMaxThreads y ThreadPool.SetMaxThreads.
Nota:
El código que hospeda Common Language Runtime puede establecer el tamaño mediante el ICorThreadpool::CorSetMaxThreads método .
Mínimos del grupo de subprocesos
El grupo de subprocesos ofrece nuevos subprocesos de trabajo o subprocesos de finalización de E/S a petición hasta que llega a un mínimo especificado para cada categoría. Puede usar el ThreadPool.GetMinThreads método para obtener estos valores mínimos.
Nota:
Cuando la demanda es baja, el número real de subprocesos del grupo de subprocesos puede descender por debajo de los valores mínimos.
Cuando se alcanza un mínimo, el grupo de subprocesos puede crear subprocesos adicionales o esperar hasta que se completen algunas tareas. El grupo de subprocesos crea y destruye subprocesos de trabajo para optimizar el rendimiento, que se define como el número de tareas que se completan por unidad de tiempo. Es posible que demasiados subprocesos no hagan un uso óptimo de los recursos disponibles, mientras que demasiados subprocesos podrían aumentar la contención de recursos.
Precaución
Puede usar el ThreadPool.SetMinThreads método para aumentar el número mínimo de subprocesos inactivos. Sin embargo, aumentar innecesariamente estos valores puede causar problemas de rendimiento. Si se inician demasiadas tareas al mismo tiempo, es posible que todas parezcan lentas. En la mayoría de los casos, el grupo de subprocesos funciona mejor con su propio algoritmo de asignación de subprocesos.
Uso del grupo de subprocesos
La manera más fácil de usar el grupo de subprocesos es usar la Biblioteca paralela de tareas (TPL). De forma predeterminada, los tipos de biblioteca TPL, como Task y Task<TResult>, usan subprocesos del grupo de subprocesos para ejecutar tareas.
También puede usar el grupo de subprocesos llamando ThreadPool.QueueUserWorkItem desde código administrado (o ICorThreadpool::CorQueueUserWorkItem desde código no administrado) y pasando un System.Threading.WaitCallback delegado que representa el método que realiza la tarea.
Otra forma de usar el grupo de subprocesos es poner en cola los elementos de trabajo que están relacionados con una operación de espera mediante el método ThreadPool.RegisterWaitForSingleObject y pasar un System.Threading.WaitHandle que, cuando se señala o cuando se agota el tiempo de espera, llame al método representado por el delegado System.Threading.WaitOrTimerCallback. Los subprocesos del grupo de subprocesos se usan para invocar métodos de devolución de llamada.
Para ver los ejemplos, compruebe las páginas de API a las que se hace referencia.
Omitir comprobaciones de seguridad
El grupo de subprocesos también proporciona los métodos ThreadPool.UnsafeQueueUserWorkItem y ThreadPool.UnsafeRegisterWaitForSingleObject. Utilice estos métodos solamente cuando tenga la seguridad de que la pila del llamador es irrelevante para las comprobaciones de seguridad que se realizan durante la ejecución de la tarea en cola. ThreadPool.QueueUserWorkItem y ThreadPool.RegisterWaitForSingleObject capturan la pila del autor de la llamada, que se combina en la pila del subproceso del grupo de subprocesos cuando el subproceso empieza a ejecutar una tarea. Si se requiere una comprobación de seguridad, se debe comprobar toda la stack. Aunque la comprobación proporciona seguridad, también tiene un costo de rendimiento.
Cuándo no usar subprocesos del grupo de subprocesos
Hay varios escenarios en los que es adecuado crear y gestionar tus propios hilos en lugar de usar hilos de grupo:
- Necesita un subproceso en primer plano.
- Necesita que un subproceso tenga una prioridad determinada.
- Tiene tareas que hacen que el subproceso se bloquee durante largos períodos de tiempo. El grupo de subprocesos tiene un número máximo de hilos, por lo que un gran número de subprocesos bloqueados podría impedir el inicio de tareas.
- Debe colocar los subprocesos en un contenedor uniproceso. Todos los subprocesos ThreadPool están en el contenedor multiproceso.
- Debe tener una identidad estable asociada al subproceso o dedicar un subproceso a una tarea.
Consulte también
- System.Threading.ThreadPool
- System.Threading.Tasks.Task
- System.Threading.Tasks.Task<TResult>
- Biblioteca paralela de tareas (TPL)
- Procedimiento: Devolución de un valor a partir de una tarea
- Objetos y características de subprocesos
- Subprocesos y subprocesamiento
- E/S de archivos asincrónica
- temporizadores