我发现，启动一个 worker_threads 需要花费 1 - 2 秒，如果作为中间层服务并不太实际，可以如果做成线程池，预启动好 max 数量的线程，通过事件来执行线程里的东西，这样会不会很快速呢？
目前用的是 egg , 如果跟 master 进程管理的模式，保证线程池数量，挂一个启动一个，然后再加一个 workerPool 层？
别用java 的思想解决node.js 的问题~
另外，worker_threads 对IO 密集型应用提升有限，增加了复杂度，甚至降低性能 （单线程没有线程切换的损耗） 对于8核以上，你开多实例即可
@zy445566 你自己实际压测下就明白了， IO 密集（读数据库）的一个接口，4核心机器测试下来 单线程并发高10%左右。 瓶颈压根不在这。
paypal 之前也有测试数据 对比 node.js 单核 4G ，java 四核8G ，node.js 并发还比 java 高一倍。
除非你是做算法或者其他CPU密集型业务，不然多线程的必要性不大
@zuohuadong 可就是会有运算的需求呢，而且没有 java 呢，现在 web 和系统都是一体，如果说 java 的思想，那么定时器算不算也是 java 的思想？
@mzTeamMeatMan 微信也有对应的函数计算啊，这种重操作就应该用函数计算，整体费用会便宜很多的。
全干不等于你所有的东西都用一个东西来干。
可以参考下 语雀 他们的实践：“云”端的语雀：用 JavaScript 全栈打造商业级应用
@mzTeamMeatMan 定时器很多语言都有，node.js 也有类似的实现和包。 如果运算需求是瓶颈的话，运算这块用C++ 写，封装成拓展，node.js 来调用。
如果是微信业务，那就有意思了，那都不叫运算需求了。
数据分析、图像处理、AI、针对特殊场景的算法… 你看看你用到了哪一个？
不要为1%的计算需求，花99% 的时间考虑。
有少量的计算，就专门开个服务偶尔跑一下，跟业务隔离开。
如果你的业务能用 java ，js 这些来做计算，那都不叫CPU 密集型。 别闹了 建议你还是先放到实际环境里运行就明白了，而不是颅内运行。
@mzTeamMeatMan 还是要拆一下的。因为你不知道什么时候eventloop里有一个阻塞任务。于是所有机器可能都挂了。
基于事件，在eventloop底层已有线程池实现了，不必再折腾
worker_threads 本身就不是和其他语言中的“线程”相同，javaScript本身就永远不可能拥有“多线程”，因为这样所以首先用起来概念上会比较“畸形”，你看看官方的第一个demo，那和普通语言下的“线程”这种概念相差甚远，那就是轻量级的能够直接共享内存对象进行通讯的“process”，放进框架里面我会觉得头晕（因为想不到要怎么做，要做成怎么样，做好了对大部分需求是否能“通用”），接着，还不知道这“process”的消耗如何。所以碰到类似情况，是我的话，要不就自己写worker_threads服务，要不就其他服务解决。倒是对worker_threads的一些使用封装会比较感兴趣。
