使用Java编写的应用, 可以编程开启多线程处理高并发业务场景.
而JS处理高并发场景使用的是 : 队列机制, 事件机制
因为JS在网页中运行时单线程模式, 在服务端nodejs中运行是单进程模式, 都无法像JAVA那样开启多个线程或者协程来处理高并发任务.
但是这不意味着JS无法处理高并发任务, 单进程的程序在使用队列机制(就是待处理任务一个个排队)处理高并发场景也仍然是非常高效的, 而且避免了开启多个线程的内存消耗.但是其缺点也是很明显的 : 不适合处理单个任务计算非常复杂消耗时间的场景.
举个栗子 :
想象一下生活中排队的场景, 如果前面有一个人磨磨唧唧, 半天赖在窗口各种问问题, 后面的人都要排队等着, 很着急.
而如果开启多个窗口(多线程/进程), 那些难缠的人分到一个窗口, 速度快的人分到一个窗口, 效率就大大提升了.
单线程，所有任务都是一条直线的执行下去，前一个任务结束，才会执行后一个任务。如果前一个任务死循环或者需要好长时间执行，后一个任务就要一直等，直到前一个执行完。为什么平时看到setTimeout那些感觉是多线程执行，那是因为线程上执行速度很快就过了，所以看到那些“延时任务”好像是马上执行。
执行方法A（设定一个定时器，这个定时器插入到队列）-funB-funC-funD；
当funD执行完了，这时候才开始执行定时器。
为什么页面会卡顿呢，以60Hz为例，即一秒钟的动画就是由60张静态图片连在一起。60fps是动画播放比较理想、比较基础的要求，windows系统有个刷新频率也是这个意思。60fps就要求一帧的时间为1s/60=16.67ms。浏览器显示页面的时候，要处理js逻辑，还要做渲染，每个执行片段的时间不能超过16.67ms。实际上，浏览器内核自身支撑体系运行也需要消耗一些时间，所以留给我们的时间差不多只有10ms。并且在处理js计算时，浏览器不会响应用户的操作，所以就造成了页面“假死”。 Web Work，就是为JavaScript创造多线程环境，允许主线程创建Web Worker线程，将一些任务分配给后台运行。在主线程运行的同事，Work线程在后台运行，两者互不干扰。等到Work线程完成计算任务再把结果返回给主线程。这样的好处是，一些密集或者高延迟的计算任务，被Work线程给分担了，这样主线程就会很流程。 Worker线程一旦创建成功，就会始终运行，不会被主线程上的活动打断取消。这样有利于随时响应主线程的通信。但是，这也造成了Worker比较耗费资源，不应该过度使用，所以一旦使用完毕，就应该关闭。 1.同源限制：分配给Worker线程运行的脚本文件，必须与主线程的脚本文件同源。 2.DOM限制：Work线程所在的全局对象和主线程不一样，所以无法读取主线程所在网页的DOM对象，也无法使用document，window，parent这些对象。但是可以使用navigator和location。 3.通信联系：Worker线程和主线程不在同一个上下文环境，他们不能直接通信，必须通过消息完成。 4.脚本限制：Worker线程不能执行alert和confirm方法，但是可以使用XMLHttpRequest对象发出的AJAX请求。 5.文件限制：Work线程不能读取本地文件，它所加载的脚本必须来自网络。
