chrome源码剖析—多线程模型

目录

引入

设计

对比

实现

总结    

问题

---

背景  

​

        日常使用多线程时，我们一般开启新线程并传入特定入口函数，接着检查函数有无副作用。若有且涉及多线程数据访问，就仔细排查，在可疑处加锁确保安全。 但 Chrome 线程模型另辟蹊径，极力避免广泛用锁。它把锁的使用严格限制在将任务放入消息队列这一环节，且只要开发者遵循其编程模型，将函数封装成任务发至合适线程执行，上层就无需操心锁的问题，大大简化开发逻辑。之所以这样做，因为浏览器太庞大了，成千上万个线程，谁能保证不出问题呢

引入

        在这里，我们引入JS单线程模型作为切入点：

        主线程始终处于处理消息的状态中，没有消息的时候自动进入休眠状态。有耗时任务时会派发给工作线程去完成，工作线程完成后重新分发到主线程里。在这个模型中，主线程必须对应一个消息队列和事件循环。在Windows的UI开发中，正好存在着这样的核心的对应关系。这不是巧合，这是设计的必然。

​

        根据上面提到的，我们大概期望的设计结果应该大致是这样的：

        如图：AsyncExcute是一个异步调用的函数，有两个回调，第一个回调是执行异步任务的回调，比如一些耗时任务；第二个回调是异步执行完成后的回调。 主线程中完全不用考虑线程安全的问题，回调2中可以直接操作UI元素，而不会带来任何问题。

        上面提到的两个回调，实际上对应了两个步骤：

               步骤1：主线程把任务派发给工作线程去处理；

               步骤2：工作线程完成后再回抛到主线程队列里面等待主线程去执行。