Javascript 多線(xiàn)程編程的前世今生

作者：騰訊技術(shù)工程 2020-06-16 14:19:50

Javascript 不是單線(xiàn)程的嗎?Javascript IO 阻塞和其他異步的需求(例如 setTimeout, Promise, requestAnimationFrame, queueMicrotask 等)不是通過(guò)事件循環(huán)(Event Loop)來(lái)解決的嗎?

作者：jolamjiang，騰訊 WXG 前端開(kāi)發(fā)工程師

一篇關(guān)于 Web Worker、SharedArrayBuffer、Atomics 的文章。

[[330324]]

為什么要多線(xiàn)程編程

大家看到文章的標(biāo)題《Javascript 多線(xiàn)程編程》可能立馬會(huì)產(chǎn)生疑問(wèn)：Javascript 不是單線(xiàn)程的嗎?Javascript IO 阻塞和其他異步的需求(例如 setTimeout, Promise, requestAnimationFrame, queueMicrotask 等)不是通過(guò)事件循環(huán)(Event Loop)來(lái)解決的嗎?

沒(méi)有錯(cuò)，Javascript 的確是單線(xiàn)程的，阻塞和其他異步的需求的確是通過(guò)實(shí)現(xiàn)循環(huán)來(lái)解決的，但是這套機(jī)制當(dāng)線(xiàn)程需要處理大規(guī)模的計(jì)算的時(shí)候就不大適用了，試想一下一下的場(chǎng)景：

你需要實(shí)現(xiàn)對(duì)文件的加解密。
你的 VirtualDom 樹(shù)有很多元素(例如上萬(wàn)個(gè))，你需要對(duì)這棵樹(shù)進(jìn)行 Diff 操作。
你需要在瀏覽器“挖礦”。

上面這些場(chǎng)景都會(huì)阻塞主線(xiàn)程，也就是當(dāng)進(jìn)行這些操作的時(shí)候，你的頁(yè)面是卡住的，設(shè)置當(dāng)頁(yè)面卡住一段時(shí)間之后，Chrome 等瀏覽器或者操作系統(tǒng)會(huì)建議你 Kill 掉整個(gè) Tab 或者進(jìn)程。這顯然不是我們想看到的事情。正因?yàn)檫@些場(chǎng)景的存在，瀏覽器提出了 W3C 在 2013 年提出了 Web Worker 草案，這個(gè)草案的提出就是為了解決上述這些問(wèn)題。

為了讓大家感受 JS 多線(xiàn)程能夠干什么，筆者寫(xiě)了一個(gè)基于 Web Worker(線(xiàn)程)、ShareArrayBuffer(共享內(nèi)存)、Atomics(鎖)等 Web API 的在前端壓縮和解壓文件(基于 DEFLATE 算法)的 demo：

Web Worker

Chrome 瀏覽器中每個(gè) Tab 都是一個(gè)進(jìn)程，每個(gè)進(jìn)程都會(huì)有一個(gè)主線(xiàn)程，網(wǎng)頁(yè)的渲染(Style, Layout, Paint, Composite)會(huì)在主線(xiàn)程進(jìn)行操作。主線(xiàn)程可以發(fā)起多個(gè) Web Worker，Web Worker 對(duì)應(yīng)“線(xiàn)程”的概念。

每個(gè) Web Worker 都對(duì)應(yīng)一個(gè)腳本文件，主線(xiàn)程可以通過(guò)像以下的代碼去發(fā)起多個(gè) Web Worker，并且通過(guò)基于事件的 API 與 Web Worker 通信：

main.js

let worker = new Worker("work.js"); 
worker.postMessage("Hello World"); 
worker.onmessage = function (event) { 
  console.log("Received message " + event.data); 
}

Web Worker 也通過(guò)相應(yīng)的實(shí)現(xiàn) API 與主線(xiàn)程進(jìn)行通信

worker.js

this.addEventListener("message", function (e) { 
  this.postMessage("You said: " + e.data); 
}, false);

Web Worker 通訊的效率與同步問(wèn)題

主線(xiàn)程與 Web Worker 通過(guò) postMessage(data: any) 通信的時(shí)候，data 會(huì)先被 copy 一份再傳給 Web Worker;同樣地，當(dāng) Web Worker 通過(guò) postMessage(data: any) 與主線(xiàn)程通信的時(shí)候，data 也會(huì)同樣先被 copy 一份再傳給主線(xiàn)程。

這樣做顯然會(huì)導(dǎo)致通信上的效率問(wèn)題，試想一下你需要在 Web Worker 里面解壓一個(gè) 1G 大小的問(wèn)題，你需要把整個(gè) 1G 的文件 copy 到 Web Worker 里，Web Worker 解壓完這個(gè) 1G 文件后，再把解壓完的文件 copy 回主線(xiàn)程里。

SharedArrayBuffer

為了解決通訊效率問(wèn)題，瀏覽器提出了 ShareArrayBuffer，ShareArrayBuffer 基于 ArrayBuffer 和 TypedArray API。ArrayBuffer 對(duì)應(yīng)一段內(nèi)存(二進(jìn)制內(nèi)容)，為了操作這段內(nèi)存，瀏覽器需要提供一些視圖(Int8Array 等)，例如可以把這段內(nèi)存當(dāng)做每 8 位一個(gè)單元的 byte 數(shù)組，每 16 位一個(gè)單元的 16 位有符號(hào)數(shù)數(shù)組。

注意：ArrayBuffer 中的二進(jìn)制流被翻譯成各種視圖的時(shí)候采用小端還是大端是由具體硬件決定的，絕大部分情況下是采用小端字節(jié)順序。

這段內(nèi)存可以在不同的 Worker 之間共享，但是內(nèi)存的共享又會(huì)產(chǎn)生另外的問(wèn)題，也就是競(jìng)爭(zhēng)的問(wèn)題(race onditions)：

計(jì)算機(jī)指令對(duì)內(nèi)存操作進(jìn)行運(yùn)算的時(shí)候，我們可以看做分兩步：一是從內(nèi)存中取值，二是運(yùn)算并給某段內(nèi)存賦值。當(dāng)我們有兩個(gè)線(xiàn)程對(duì)同一個(gè)內(nèi)存地址進(jìn)行 +1 操作的時(shí)候，假設(shè)線(xiàn)程是先后順序運(yùn)行的，為了簡(jiǎn)化模型，我們可以如下圖表示：

上面兩個(gè)線(xiàn)程的運(yùn)行結(jié)果也符合我們的預(yù)期，也即線(xiàn)程分別都對(duì)同一地址進(jìn)行了 +1 操作，最后得到結(jié)果 3。但因?yàn)閮蓚€(gè)線(xiàn)程是同時(shí)運(yùn)行的，往往會(huì)發(fā)生下圖所表示的問(wèn)題，也即讀取與寫(xiě)入可能不在一個(gè)事務(wù)中發(fā)生：

這種情況就叫做競(jìng)爭(zhēng)問(wèn)題(Race Condition)。

Atomics

為了解決上述的競(jìng)爭(zhēng)問(wèn)題，瀏覽器提供了 Atomics API，這組 API 是一組原子操作，可以將讀取和寫(xiě)入綁定起來(lái)，例如下圖中的 S1 到 S3 操作就被瀏覽器封裝成 Atomics.add() 這個(gè) API，從而解決競(jìng)爭(zhēng)問(wèn)題。

Atomics API 具體包含：

Atomics.add()
Atomics.and()
Atomics.compareExchange()
Atomics.exchange()
Atomics.isLockFree()
Atomics.load()
Atomics.notify()
Atomics.or()
Atomics.store()
Atomics.sub()
Atomics.wait()
Atomics.xor()

有了這套 API，我們可以實(shí)現(xiàn)像 Golang 中的 Golang Synchronization Primitives 的功能。Mutex 和 Cond 的實(shí)現(xiàn)會(huì)在下面介紹。

WebAssembly

有了 SharedArrayBuffer 和 Atomics 能力之后，證明瀏覽器能夠提供內(nèi)存共享和鎖的實(shí)現(xiàn)了，也就是說(shuō) WebAssembly 線(xiàn)程在瀏覽器機(jī)制上能夠高效地得到保證。

其實(shí)我嚴(yán)重懷疑 SharedArrayBuffer 和 Atomics 是為了支持 WebAssembly 才把 API 順便提供給 JS Runtime 的，因?yàn)槟壳盀橹箾](méi)有看到 ES 有比較豐富的關(guān)于鎖的草案(例如像 Java 中的 synchronized 關(guān)鍵字)。

Mutext 和 Cond 的實(shí)現(xiàn)

上面提到了，基于 ShareArrayBuffer 和 Atomics 可以開(kāi)發(fā)像 Golang Synchronization Primitives 一樣的 API，下面介紹一下 Mutex 和 Cond 的實(shí)現(xiàn)。實(shí)現(xiàn)的介紹是基于 Mozzila Javascript 編譯器工程師 Lars T Hansen 實(shí)現(xiàn)關(guān)于鎖的庫(kù)。

Mutex

首先說(shuō)一下 Mutex 的功能，Mutex 的 API 大概是這樣的：

let mutex = new Lock(shareArrayBuffer, ...); 
mutex.lock(); 
doSomething(); 
mutex.unlock();

Mutex 可以保證 lock() 和 unlock() 之間的代碼代碼不會(huì)被打斷。下面是介紹具體實(shí)現(xiàn)：

首先定義 Mutex 的三個(gè)狀態(tài)以及對(duì)應(yīng)的狀態(tài)機(jī)

UNLOCK: 未鎖定
LOCKED: 被鎖定
WAITED: 被鎖定且大于等于 1 個(gè)線(xiàn)程在等待該鎖

對(duì)于 Worker 線(xiàn)程來(lái)說(shuō) Mutex 的每個(gè)狀態(tài)都可能是初始態(tài)，狀態(tài)與狀態(tài)間扭轉(zhuǎn)會(huì)產(chǎn)生一些操作且進(jìn)入下一狀態(tài)：

加鎖 lock()

初始狀態(tài)為UNLOCK: 鎖未被搶占，將狀態(tài)扭轉(zhuǎn)為 LOCKED，線(xiàn)程進(jìn)行后續(xù)操作。
初始狀態(tài)為L(zhǎng)OCKED: 鎖已被搶占，將狀態(tài)扭轉(zhuǎn)為 WAITED，并將線(xiàn)程設(shè)置為等待態(tài)，并將線(xiàn)程設(shè)置為當(dāng)鎖的狀態(tài)不為 WAITED 的時(shí)候可能被喚醒，一旦被喚醒則該線(xiàn)程擁有鎖，線(xiàn)程進(jìn)行后續(xù)操作。
初始狀態(tài)為WAITED: 鎖已被搶占，并將線(xiàn)程設(shè)置為等待態(tài)，并將線(xiàn)程設(shè)置為當(dāng)鎖的狀態(tài)不為 WAITED 的時(shí)候可能被喚醒，一旦被喚醒則該線(xiàn)程擁有鎖，線(xiàn)程進(jìn)行后續(xù)操作。

釋放 unlock()

1.初始狀態(tài)為L(zhǎng)OCKED: 鎖被搶占且未被等待，將狀態(tài)扭轉(zhuǎn)為 UNLOCK，線(xiàn)程進(jìn)行后續(xù)操作。

2.初始狀態(tài)為WAITED: 鎖被搶占且被等待，將狀態(tài)扭轉(zhuǎn)為 LOCKED，喚醒一個(gè)在等待態(tài)的線(xiàn)程，線(xiàn)程進(jìn)行后續(xù)操作。

上面描述的邏輯的對(duì)應(yīng)的代碼如下：

// lock 
Lock.prototype.lock = function () { 
  const iab = this._iab; 
  const stateIdx = this._ibase; 
  let c; 
  if ((c = Atomics.compareExchange(iab, stateIdx, 0, 1)) != 0) { 
    do { 
      if (c == 2 || Atomics.compareExchange(iab, stateIdx, 1, 2) != 0) 
        Atomics.wait(iab, stateIdx, 2); 
    } while ((c = Atomics.compareExchange(iab, stateIdx, 0, 2)) != 0); 
  } 
} 
 
// unlock 
Lock.prototype.unlock = function () { 
    const iab = this._iab; 
    const stateIdx = this._ibase; 
    let v0 = Atomics.sub(iab, stateIdx, 1); 
    // Wake up a waiter if there are any 
    if (v0 != 1) { 
        Atomics.store(iab, stateIdx, 0); 
        Atomics.notify(iab, stateIdx, 1); 
    } 
}

可以看到鎖的實(shí)現(xiàn)用到了 Atomics.compareExchange() 和 Atomics.wait()(相當(dāng)于 Linux 中的 futex)兩個(gè)原子操作。

Cond

Cond 是基于 Mutex 實(shí)現(xiàn)的，它的大致功能是持有鎖的情況下可進(jìn)行兩種操作：

wait(): 本線(xiàn)程進(jìn)度進(jìn)入等待態(tài)，并且被喚醒的時(shí)候重新持有鎖。
notifyOne(): 喚醒一個(gè)正在等待態(tài)的線(xiàn)程。

具體使用方法如下：

// thread A 
var msg = new Int32Array(sab, msgLoc, 1); 
lock.lock(); 
while (msg[0] < numWorkers) 
 cond.wait(); 
lock.unlock(); 
 
// thread B, C, D, E, … 
var msg = new Int32Array(sab, msgLoc, 1); 
lock.lock(); 
msg[0]++; 
cond.notifyOne(); 
lock.unlock();

由于 Cond 是基于 Mutex，前置條件是持有鎖，后置條件是釋放鎖，你可以看做 Cond 只有兩個(gè)狀態(tài)：

NORMAL: 非等待態(tài)，調(diào)用 wait() 轉(zhuǎn)化為 WAITED 狀態(tài)，并把線(xiàn)程設(shè)置為等待態(tài)，并且被喚醒的時(shí)候重新持有鎖，然后進(jìn)行后續(xù)操作。
WAITED: 等待態(tài)(不對(duì)應(yīng)上述 Lock 的 WAITED 態(tài))，調(diào)用 notifyOne() 將狀態(tài)設(shè)置為 NORMAL 態(tài)，重新喚醒一個(gè)處于等待態(tài)的線(xiàn)程，然后進(jìn)行后續(xù)操作。

異步鎖

上述介紹的鎖都是同步的，Atomics.wait 不能在主線(xiàn)程使用，在主線(xiàn)程使用的話(huà)瀏覽器會(huì)拋出異常：

Uncaught TypeError: Atomics.wait cannot be called in this context

所以我們需要設(shè)計(jì)所謂的”異步鎖“，所謂的異步鎖原理很簡(jiǎn)單，就是將同步鎖里面的 Atomics.wait() 操作交給一個(gè)新的線(xiàn)程，主線(xiàn)程和這個(gè)線(xiàn)程通過(guò)事件通信來(lái)異步化這里的操作。具體實(shí)現(xiàn)可以參照這個(gè)文件)。

demo 實(shí)現(xiàn)

介紹完上述的知識(shí)之后，就可以用相關(guān)的 API 就可以實(shí)現(xiàn)我們的 demo 了，首先畫(huà)一下我們 demo 的架構(gòu)圖：

如圖所示，在線(xiàn)解壓縮這個(gè) demo 主要分為兩個(gè)線(xiàn)程：

主線(xiàn)程：負(fù)責(zé)調(diào)用 Dom API 等，主要負(fù)責(zé) UI 更新。

工作線(xiàn)程：負(fù)責(zé)文件的壓縮/解壓。

兩個(gè)線(xiàn)程間的通信是通過(guò)讀寫(xiě)兩段共享內(nèi)存來(lái)實(shí)現(xiàn)的，對(duì)于共享內(nèi)存的訪問(wèn)，通過(guò)鎖來(lái)解決競(jìng)爭(zhēng)問(wèn)題。需要注意的是，主線(xiàn)程的寫(xiě)緩存也即工作線(xiàn)程的讀緩存，反之亦然。

demo 的具體實(shí)現(xiàn)可以參照 demo 的 Github 地址。

目前多線(xiàn)程編程的不足

目前只通過(guò)瀏覽器提供的 API 來(lái)進(jìn)多線(xiàn)程開(kāi)發(fā)的話(huà)成本非常大，主要有兩方面問(wèn)題：

過(guò)于底層的 API

1.需要你實(shí)現(xiàn)語(yǔ)言級(jí)、或者系統(tǒng)級(jí)的 lock API，參照 Golang 的 lock API。

2.沒(méi)有語(yǔ)法上的支持，例如 Java synchronized 關(guān)鍵字等。

普通的 Javascript Object 無(wú)法共享

這其實(shí)也是 API 過(guò)于底層的另一方面的體現(xiàn)，也就是說(shuō)對(duì) JS 對(duì)象進(jìn)行內(nèi)存共享的話(huà)，你需要開(kāi)辟一段 SharedArrayBuffer，然后在此之上實(shí)現(xiàn)對(duì) JS 對(duì)象的序列化、反序列化、更新等操作，實(shí)現(xiàn)成本也是比較大的。

事實(shí)上我們也不應(yīng)該輕易手動(dòng)實(shí)現(xiàn)相關(guān)的庫(kù)或者功能，因?yàn)橄嚓P(guān)領(lǐng)域的問(wèn)題非常復(fù)雜、需要仔細(xì)的設(shè)計(jì)和實(shí)現(xiàn)。例如我們可以先使用下面這兩個(gè)庫(kù)：

parlib-simple: 這個(gè)庫(kù)里面有類(lèi)似于 Golang 里面 channel 一樣的 API。
js-lock-and-condition: 這里庫(kù)有 Mutex 和 Cond 實(shí)現(xiàn)。

總結(jié)

瀏覽器提供給了我們進(jìn)行多線(xiàn)程的能力，例如 PWA 或者 WebAseembly 與 JS 混用等場(chǎng)景都會(huì)用到上述的機(jī)制，如果你想實(shí)現(xiàn)一個(gè)高性能的網(wǎng)頁(yè)客戶(hù)端程序(例如 Figma 一樣的殺手級(jí)應(yīng)用)，你最好也用上上述的機(jī)制。值得注意的是，用了鎖可能會(huì)降低你的程序的性能，具體要看線(xiàn)程切換和等待是的成本是否能夠抵消內(nèi)存拷貝的成本，例如 demo 完全可以改成無(wú)鎖的，代價(jià)將文件內(nèi)容拷貝到共享線(xiàn)程，并把工作線(xiàn)程的內(nèi)容拷貝回主線(xiàn)程。

雖然上面建議不要輕易實(shí)現(xiàn)自己的庫(kù)，例如上面的 lock 代碼短短幾行，但是其中的推導(dǎo)可以足夠?qū)懯畮醉?yè)的 Paper 了，但是這里的基礎(chǔ)能力很匱乏，據(jù)筆者了解，TC39 提案中鮮少出現(xiàn)關(guān)于多線(xiàn)程編程的提案，目前僅發(fā)現(xiàn)以下這個(gè)：

proposal-atomics-wait-async

但是，如果自信有能力和時(shí)間建設(shè)這些基礎(chǔ)能力的話(huà)，這個(gè)領(lǐng)域的確是“廣闊天地，大有作為”，特別是如果你的項(xiàng)目準(zhǔn)備用 WebAseembly 和 JS 混用的情況(例如 Figma 就是用了 WebAssembly 和 React)。

責(zé)任編輯：武曉燕來(lái)源： 51CTO

Javascript 多線(xiàn)程編程