JS和C#/JAVA的多线程，究竟有什么不一样?

JS和C#/JAVA的多线程，究竟有什么不一样？| 这么说，相信你应该能明白。

JS是单线程事件驱动模型，语言本身是不支持多线程的，但Web和Node运行时，在各自的运行环境中实现了多线程，Web中实现多线程的模块是Worker、SharedWorker、ServiceWorker等，而Node环境中则是 worker_threads、cluster、child_process等。所以，JS中的I/O密集的高并发可以通过事件机制处理，而CPU密集的并行任务，可以启用多线程。

而C#是天生支持多线程的，主要的实现方式有Thread、ThreadPool和Task。其中Thread需要手动创建和销毁线程，而ThreadPool和Task的线程，托管在后台管理的线程池中，自动管理线程的创建和销毁，可以实现线程的复用，避免线程的创建销毁的资源消耗。但是，C#没有事件机制，高并发和并行任务，都是依靠多线程来完成。JAVA的多线程和C#类似。

这么说，JS和C#，好像都能解决高并发和并行任务。但是两者的多线程还是有本质区别。（1）JS的多线程，无论是Web还是在Node环境中，都是基于消息通信，线程之间的资源是相互隔离的，主线程和子线程之间，通过消息进行通讯。首先，创建资源隔离的线程就比较消耗资源，而消息通讯的过程也比较消耗资源，特别是需要处理消息数据的序列化和反序列化。所以，使用JS的多线程时，要想清楚是否真得需要，能用事件机制解决的，就不要用动用多线程。（2）而C#的多线程，是基于内存共享的，线程之间共享数据，所以效率会高很多，但这种模式需要注意资源争抢和死锁的问题。而现代C#的多线程，基本都是基于后台托管的线程池，所以可以有效避免线程创建和销毁的消耗，同时通过Task、async/await等方式，即可以优雅的使用多线程，又能安全的避开死锁等安全问题，基本上不需要有啥心智负担。

再补充说一下鸿蒙ArkTS中的魔法，我也只是看文档，具体表现以及实现原理不清楚。在ArkTS中，新增了TaskPool，实现了多线程的池化管理，在4.1版本中，更是实现了消息对象的引用共享，即不需要序列化和反序列化，这些魔法能够大大提升多线程的执行效率和安全性。

#多线程#