Nuestro team especializado despúes de muchos días de trabajo y recopilar de información, obtuvimos la respuesta, deseamos que te sea de gran utilidad en tu plan.
Solución:
De acuerdo, las corrutinas se comparan más a menudo con los subprocesos que con las tareas que ejecuta en un grupo de subprocesos determinado. Un Ejecutor es ligeramente diferente en el sentido de que tiene algo que administra subprocesos y pone en cola tareas para ejecutarse en esos subprocesos.
También les confesaré que solo llevo unos 6 meses usando las cortinas y actores de Kotlin sólidamente, pero sigamos.
E/S asíncrono
Entonces, creo que una gran diferencia es que ejecutar su tarea en una rutina le permitirá lograr la concurrencia en un solo subproceso para una tarea de IO si esa tarea es una tarea de IO verdaderamente asíncrona que produce el control correctamente mientras la tarea de IO aún se está completando. . Puede lograr lecturas/escrituras simultáneas muy livianas con rutinas de esta manera. Podría lanzar 10 000 corrutinas, todas leyendo desde el disco al mismo tiempo en 1 subproceso y sucedería al mismo tiempo. Puede leer más sobre async IO aquí async io wiki
Por otro lado, para un servicio Executor, si tuviera 1 subproceso en su grupo, sus múltiples tareas de IO se ejecutarían y bloquearían en serie en ese subproceso. Incluso si estuviera usando una biblioteca asíncrona.
Concurrencia estructurada
Con las corrutinas y el alcance de las corrutinas, obtienes algo llamado simultaneidad estructurada. Esto significa que tiene que hacer mucho menos mantenimiento de libros sobre las diversas tareas en segundo plano que está ejecutando para que pueda limpiar adecuadamente esas tareas si ingresa en alguna ruta de error. Con su albacea, necesitaría realizar un seguimiento de su futuro y hacer la limpieza usted mismo. Aquí hay un artículo realmente bueno escrito por uno de los líderes del equipo de Kotlin para explicar completamente esta sutileza. Concurrencia estructurada
Interacción con los actores
Otra ventaja de nicho, probablemente más importante, es que con rutinas, productores y consumidores, puedes interactuar con Actores. Los actores encapsulan el estado y logran una concurrencia segura de subprocesos a través de la comunicación en lugar de las herramientas sincronizadas tradicionales. Al usar todo esto, puede lograr un peso muy ligero y un estado altamente concurrente con muy poca sobrecarga de subprocesos. Los ejecutores simplemente no ofrecen la capacidad de interactuar con el estado sincronizado en algo como un actor con, por ejemplo, 10 000 hilos o incluso 1000 hilos. Felizmente podría lanzar 100 000 rutinas, y si las tareas se suspenden y ceden el control en los puntos adecuados, puede lograr algunas cosas excelentes. Puedes leer más aquí Estado mutable compartido
peso ligero
Y finalmente, solo para demostrar cuán liviana es la concurrencia de corrutina, lo desafiaría a hacer algo como esto en un ejecutor y ver cuál es el tiempo total transcurrido (esto se completó en 1160 milisegundos en mi máquina):
fun main() = runBlocking
val start = System.currentTimeMillis()
val jobs = List(10_000)
launch
delay(1000) // delays for 1000 millis
print(".")
jobs.forEach it.join()
val end = System.currentTimeMillis()
println()
println(end-start)
Probablemente haya otras cosas, pero como dije, todavía estoy aprendiendo.