Worker可用线程数量少，无法满足应用平移适配需求，部分应用可能超过200个线程。 TaskPool和Worker都无法提供对等的线程数量，应该如何设计大量线程并发方案？

Worker可用线程数量少，无法满足应用平移适配需求，部分应用可能超过200个线程。 TaskPool和Worker都无法提供对等的线程数量，应该如何设计大量线程并发方案？

解决方案

系统采用ArkTS作为开发语言，由于底层线程模型对接了libuv，因此在应用进程启动后，会有多个I/O线程用于I/O操作，JS线程的I/O异步操作，会在I/O线程执行，JS线程可以同时执行其他操作，不存在阻塞等待问题。 同时，ArkTS提供了TaskPool并发API，类似GCD的线程池能力，可以执行任务，而且不需要开发者进行线程生命周期管理。 因此针对需要大量线程的问题，开发建议如下: 将多线程任务转变为并发任务，通过TaskPool分发执行 I/O型任务不需要单独开启线程，而是在当前线程（可以是TaskPool线程）执行 少量需要常驻的CPU密集型任务，采用Worker，并且需要控制在8个及以下。

参考链接

1. TaskPool和Worker的对比 (TaskPool和Worker)