En los viejos tiempos, la memoria no estaba virtualizada ni protegida y cualquier código podía escribir en cualquier lugar. En aquellos días, un diseño de un hilo para una CPU tenía sentido. En las décadas posteriores, la memoria primero se protegió y luego se virtualizó. Piensa en los hilos como núcleos virtuales - una especie de promesa de que en algún momento, cuando tus datos y tu código estén listos, ese hilo será empujado ( o programado, como lo llaman los ingenieros y matemáticos que investigan los algoritmos de programación ) en una CPU real para hacer un trabajo real.

• https://people.eecs.berkeley.edu/%7Ercs/research/interactive_latency.html

Ahora - debido a las magnitudes de la diferencia en el tiempo - la CPU y la caché operan tan rápido en comparación con la obtención de datos desde el almacenamiento o la red - que miles de hilos podrían ir y venir mientras un hilo está esperando a que www.google.com entregue un paquete o dos de datos, así que esa es la razón por la que ves tantos hilos más que la CPU real.

Si conviertes las operaciones de los hilos que ocurren en la escala de tiempo negro / azul y las conviertes a un segundo = 1 ns, las cosas que nos importan son más como la IO del disco toman 100 microsegundos son como 4 días y un viaje de ida y vuelta de Internet de 200 ms es un retraso de 20 años si estás contando segundos en la escala de tiempo de la CPU. Como muchos ejercicios de potencias de diez En casi todos los casos, la CPU permanece inactiva durante "meses" a la espera de un trabajo significativo de un mundo externo muy, muy lento.

No parece que haya nada raro en la imagen que has colgado, así que tal vez estemos malinterpretando lo que quieres decir al preguntarte por los hilos.

Si haces clic con el botón derecho (clic de control) en la palabra hilos en la fila de la cabecera en la parte superior, añade el estado de la aplicación y verás que la mayoría de los hilos están probablemente inactivos, durmiendo, no se están ejecutando en un momento dado.

No se hace la pregunta, posiblemente más fundamental, de "¿Cómo puedo tener 290 procesos si mi CPU sólo tiene cuatro núcleos?". Esta respuesta es un poco de historia, que puede ayudarte a entender el panorama general, aunque la pregunta específica ya ha sido respondida. Por lo tanto, no voy a dar una versión TL;DR.

Hace tiempo (pensemos en los años 50-60), los ordenadores sólo podían hacer una cosa a la vez. Eran muy caros, llenaban habitaciones enteras y necesitábamos una forma de hacer un uso eficiente de ellos compartiéndolos entre varias personas. La primera forma de hacerlo fue procesamiento por lotes El sistema de gestión de la información, en el que los usuarios enviaban tareas al ordenador y éstas se ponían en cola, se ejecutaban una tras otra y los resultados se enviaban al usuario. Eso estaba bien, pero significaba que, si querías hacer un cálculo que iba a llevar un par de días, nadie más podía usar el ordenador durante ese tiempo.

La siguiente innovación (pensemos en los años 60-70) fue tiempo compartido . Ahora, en lugar de ejecutar la totalidad de una tarea, y luego la totalidad de la siguiente, el ordenador ejecutaría un trozo de una tarea, luego la pausaría y ejecutaría un trozo de la siguiente, y así sucesivamente. De este modo, el ordenador daría la impresión de estar ejecutando varios procesos simultáneamente. La gran ventaja de esto es que ahora puedes ejecutar un cálculo que te llevará un par de días y, aunque ahora tardará aún más, porque se sigue interrumpiendo, otras personas pueden seguir utilizando la máquina durante ese tiempo.

Todo esto era para enormes ordenadores de tipo mainframe. Cuando los ordenadores personales empezaron a popularizarse, al principio no eran muy potentes y, además, como eran personal parecía correcto que sólo pudieran hacer una cosa -ejecutar una aplicación- a la vez (pensemos en los años 80). Pero, a medida que se hicieron más potentes (desde los años 90 hasta la actualidad), la gente quiso que sus ordenadores personales también compartieran el tiempo.

Así que acabamos con ordenadores personales que daban la ilusión de ejecutar múltiples procesos de forma concurrente, pero que en realidad los ejecutaban de uno en uno durante breves periodos de tiempo y luego los ponían en pausa. Los hilos son esencialmente lo mismo: con el tiempo, la gente quería que incluso los procesos individuales dieran la ilusión de hacer varias cosas simultáneamente. Al principio, el escritor de la aplicación tenía que encargarse de ello: pasar un rato actualizando los gráficos, pausar eso, pasar un rato calculando, pausar eso, pasar un rato haciendo otra cosa, ...

Sin embargo, el sistema operativo ya era bueno en la gestión de múltiples procesos, tenía sentido ampliarlo para gestionar estos subprocesos, que se llaman hilos. Así, ahora tenemos un modelo en el que cada proceso (o aplicación) contiene al menos un hilo, pero algunos contienen varios o muchos. Cada uno de estos hilos corresponde a una subtarea algo independiente.

Pero, en el nivel superior, la CPU sigue dando la ilusión de que todos estos hilos están funcionando al mismo tiempo. En realidad, está ejecutando uno durante un rato, pausándolo, eligiendo otro para ejecutarlo durante un rato, y así sucesivamente. Excepto que las CPUs modernas pueden ejecutar más de un hilo a la vez. Así que, en el real En realidad, el sistema operativo está jugando a este juego de "ejecutar durante un rato, pausar, ejecutar otra cosa durante un rato, pausar" en todos los núcleos simultáneamente. Así que puedes tener tantos hilos como quieras (y los diseñadores de tu aplicación) pero, en cualquier momento, todos menos unos pocos estarán realmente en pausa.