Tienes un servicio existente sobre un pool de doscientos hilos que pasa la mayor parte del tiempo esperando llamadas downstream. ¿Lo pasarías a hilos virtuales, y cómo?

Sí, si el trabajo es E/S bloqueante y no intensivo en CPU. Cambia el servidor y cualquier executor de tareas a un executor de un hilo virtual por tarea, y luego quita los supuestos que te daba el pool viejo: añade límites explícitos de concurrencia downstream con semáforos o pools de conexiones, audita los bloques synchronized y las llamadas nativas que pueden hacer pinning de un portador, y revisa el uso de thread locals. Despliégalo tras un flag y compara rendimiento y latencia de cola.

Si los hilos están sobre todo parados esperando HTTP o base de datos, sí, porque doscientos hilos son también doscientas peticiones concurrentes, y todo lo demás hace cola detrás. El cambio en sí es pequeño: ejecutar el servidor web sobre hilos virtuales y cambiar los executors de tareas por uno que cree un hilo virtual por tarea. El trabajo está en lo que el pool hacía de forma implícita. Era un límite de concurrencia, así que en cuanto desaparece puedo tener de golpe diez mil peticiones golpeando una base de datos con un pool de cincuenta conexiones, y en vez de una cola en el pool de hilos me salen timeouts en el pool de conexiones. Así que devuelvo los límites explícitos a donde corresponden, normalmente un semáforo por dependencia downstream dimensionado a conciencia. Luego audito el pinning, que es mucho menos problema en las versiones recientes ya que synchronized ya no hace pinning, pero las llamadas nativas sí. También reviso si hay thread locals guardando algo grande, porque las cachés por hilo que estaban bien con doscientos hilos no lo están con cien mil. Después subo tráfico tras un flag y vigilo la latencia de cola, no solo el rendimiento.