Javascript 多線程編程的前世今生
作者：jolamjiang，騰訊 WXG 前端開發(fā)工程師
一篇關(guān)于 Web Worker、SharedArrayBuffer、Atomics 的文章。
為什么要多線程編程
大家看到文章的標題《Javascript 多線程編程》可能立馬會產(chǎn)生疑問：Javascript 不是單線程的嗎?Javascript IO 阻塞和其他異步的需求(例如 setTimeout, Promise, requestAnimationFrame, queueMicrotask 等)不是通過事件循環(huán)(Event Loop)來解決的嗎?
沒有錯，Javascript 的確是單線程的，阻塞和其他異步的需求的確是通過實現(xiàn)循環(huán)來解決的，但是這套機制當線程需要處理大規(guī)模的計算的時候就不大適用了，試想一下一下的場景：
- 你需要實現(xiàn)對文件的加解密。
- 你的 VirtualDom 樹有很多元素(例如上萬個)，你需要對這棵樹進行 Diff 操作。
- 你需要在瀏覽器“挖礦”。
上面這些場景都會阻塞主線程，也就是當進行這些操作的時候，你的頁面是卡住的，設置當頁面卡住一段時間之后，Chrome 等瀏覽器或者操作系統(tǒng)會建議你 Kill 掉整個 Tab 或者進程。這顯然不是我們想看到的事情。正因為這些場景的存在，瀏覽器提出了 W3C 在 2013 年提出了 Web Worker 草案，這個草案的提出就是為了解決上述這些問題。
為了讓大家感受 JS 多線程能夠干什么，筆者寫了一個基于 Web Worker(線程)、ShareArrayBuffer(共享內(nèi)存)、Atomics(鎖)等 Web API 的在前端壓縮和解壓文件(基于 DEFLATE 算法)的 demo：
Web Worker
Chrome 瀏覽器中每個 Tab 都是一個進程，每個進程都會有一個主線程，網(wǎng)頁的渲染(Style, Layout, Paint, Composite)會在主線程進行操作。主線程可以發(fā)起多個 Web Worker，Web Worker 對應“線程”的概念。
每個 Web Worker 都對應一個腳本文件，主線程可以通過像以下的代碼去發(fā)起多個 Web Worker，并且通過基于事件的 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 也通過相應的實現(xiàn) API 與主線程進行通信
worker.js
- this.addEventListener("message", function (e) {
- this.postMessage("You said: " + e.data);
- }, false);
Web Worker 通訊的效率與同步問題
主線程與 Web Worker 通過 postMessage(data: any) 通信的時候，data 會先被 copy 一份再傳給 Web Worker;同樣地，當 Web Worker 通過 postMessage(data: any) 與主線程通信的時候，data 也會同樣先被 copy 一份再傳給主線程。
這樣做顯然會導致通信上的效率問題，試想一下你需要在 Web Worker 里面解壓一個 1G 大小的問題，你需要把整個 1G 的文件 copy 到 Web Worker 里，Web Worker 解壓完這個 1G 文件后，再把解壓完的文件 copy 回主線程里。
SharedArrayBuffer
為了解決通訊效率問題，瀏覽器提出了 ShareArrayBuffer，ShareArrayBuffer 基于 ArrayBuffer 和 TypedArray API。ArrayBuffer 對應一段內(nèi)存(二進制內(nèi)容)，為了操作這段內(nèi)存，瀏覽器需要提供一些視圖(Int8Array 等)，例如可以把這段內(nèi)存當做每 8 位一個單元的 byte 數(shù)組，每 16 位一個單元的 16 位有符號數(shù)數(shù)組。
注意：ArrayBuffer 中的二進制流被翻譯成各種視圖的時候采用小端還是大端是由具體硬件決定的，絕大部分情況下是采用小端字節(jié)順序。
這段內(nèi)存可以在不同的 Worker 之間共享，但是內(nèi)存的共享又會產(chǎn)生另外的問題，也就是競爭的問題(race onditions)：
計算機指令對內(nèi)存操作進行運算的時候，我們可以看做分兩步：一是從內(nèi)存中取值，二是運算并給某段內(nèi)存賦值。當我們有兩個線程對同一個內(nèi)存地址進行 +1 操作的時候，假設線程是先后順序運行的，為了簡化模型，我們可以如下圖表示：
上面兩個線程的運行結(jié)果也符合我們的預期，也即線程分別都對同一地址進行了 +1 操作，最后得到結(jié)果 3。但因為兩個線程是同時運行的，往往會發(fā)生下圖所表示的問題，也即讀取與寫入可能不在一個事務中發(fā)生：
這種情況就叫做競爭問題(Race Condition)。
Atomics
為了解決上述的競爭問題，瀏覽器提供了 Atomics API，這組 API 是一組原子操作，可以將讀取和寫入綁定起來，例如下圖中的 S1 到 S3 操作就被瀏覽器封裝成 Atomics.add() 這個 API，從而解決競爭問題。
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，我們可以實現(xiàn)像 Golang 中的 Golang Synchronization Primitives 的功能。Mutex 和 Cond 的實現(xiàn)會在下面介紹。
WebAssembly
有了 SharedArrayBuffer 和 Atomics 能力之后，證明瀏覽器能夠提供內(nèi)存共享和鎖的實現(xiàn)了，也就是說 WebAssembly 線程在瀏覽器機制上能夠高效地得到保證。
其實我嚴重懷疑 SharedArrayBuffer 和 Atomics 是為了支持 WebAssembly 才把 API 順便提供給 JS Runtime 的，因為目前為止沒有看到 ES 有比較豐富的關(guān)于鎖的草案(例如像 Java 中的 synchronized 關(guān)鍵字)。
Mutext 和 Cond 的實現(xiàn)
上面提到了，基于 ShareArrayBuffer 和 Atomics 可以開發(fā)像 Golang Synchronization Primitives 一樣的 API，下面介紹一下 Mutex 和 Cond 的實現(xiàn)。實現(xiàn)的介紹是基于 Mozzila Javascript 編譯器工程師 Lars T Hansen 實現(xiàn)關(guān)于鎖的庫。
Mutex
首先說一下 Mutex 的功能，Mutex 的 API 大概是這樣的：
- let mutex = new Lock(shareArrayBuffer, ...);
- mutex.lock();
- doSomething();
- mutex.unlock();
Mutex 可以保證 lock() 和 unlock() 之間的代碼代碼不會被打斷。下面是介紹具體實現(xiàn)：
首先定義 Mutex 的三個狀態(tài)以及對應的狀態(tài)機
- UNLOCK: 未鎖定
- LOCKED: 被鎖定
- WAITED: 被鎖定且大于等于 1 個線程在等待該鎖
對于 Worker 線程來說 Mutex 的每個狀態(tài)都可能是初始態(tài)，狀態(tài)與狀態(tài)間扭轉(zhuǎn)會產(chǎn)生一些操作且進入下一狀態(tài)：
加鎖 lock()
- 初始狀態(tài)為UNLOCK: 鎖未被搶占，將狀態(tài)扭轉(zhuǎn)為 LOCKED，線程進行后續(xù)操作。
- 初始狀態(tài)為LOCKED: 鎖已被搶占，將狀態(tài)扭轉(zhuǎn)為 WAITED，并將線程設置為等待態(tài)，并將線程設置為當鎖的狀態(tài)不為 WAITED 的時候可能被喚醒，一旦被喚醒則該線程擁有鎖，線程進行后續(xù)操作。
- 初始狀態(tài)為WAITED: 鎖已被搶占，并將線程設置為等待態(tài)，并將線程設置為當鎖的狀態(tài)不為 WAITED 的時候可能被喚醒，一旦被喚醒則該線程擁有鎖，線程進行后續(xù)操作。
釋放 unlock()
1.初始狀態(tài)為LOCKED: 鎖被搶占且未被等待，將狀態(tài)扭轉(zhuǎn)為 UNLOCK，線程進行后續(xù)操作。
2.初始狀態(tài)為WAITED: 鎖被搶占且被等待，將狀態(tài)扭轉(zhuǎn)為 LOCKED，喚醒一個在等待態(tài)的線程，線程進行后續(xù)操作。
上面描述的邏輯的對應的代碼如下：
- // 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);
- }
- }
可以看到鎖的實現(xiàn)用到了 Atomics.compareExchange() 和 Atomics.wait()(相當于 Linux 中的 futex)兩個原子操作。
Cond
Cond 是基于 Mutex 實現(xiàn)的，它的大致功能是持有鎖的情況下可進行兩種操作：
- wait(): 本線程進度進入等待態(tài)，并且被喚醒的時候重新持有鎖。
- notifyOne(): 喚醒一個正在等待態(tài)的線程。
具體使用方法如下：
- // 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 只有兩個狀態(tài)：
- NORMAL: 非等待態(tài)，調(diào)用 wait() 轉(zhuǎn)化為 WAITED 狀態(tài)，并把線程設置為等待態(tài)，并且被喚醒的時候重新持有鎖，然后進行后續(xù)操作。
- WAITED: 等待態(tài)(不對應上述 Lock 的 WAITED 態(tài))，調(diào)用 notifyOne() 將狀態(tài)設置為 NORMAL 態(tài)，重新喚醒一個處于等待態(tài)的線程，然后進行后續(xù)操作。
異步鎖
上述介紹的鎖都是同步的，Atomics.wait 不能在主線程使用，在主線程使用的話瀏覽器會拋出異常：
- Uncaught TypeError: Atomics.wait cannot be called in this context
所以我們需要設計所謂的”異步鎖“，所謂的異步鎖原理很簡單，就是將同步鎖里面的 Atomics.wait() 操作交給一個新的線程，主線程和這個線程通過事件通信來異步化這里的操作。具體實現(xiàn)可以參照這個文件)。
demo 實現(xiàn)
介紹完上述的知識之后，就可以用相關(guān)的 API 就可以實現(xiàn)我們的 demo 了，首先畫一下我們 demo 的架構(gòu)圖：
如圖所示，在線解壓縮這個 demo 主要分為兩個線程：
主線程：負責調(diào)用 Dom API 等，主要負責 UI 更新。
工作線程：負責文件的壓縮/解壓。
兩個線程間的通信是通過讀寫兩段共享內(nèi)存來實現(xiàn)的，對于共享內(nèi)存的訪問，通過鎖來解決競爭問題。需要注意的是，主線程的寫緩存也即工作線程的讀緩存，反之亦然。
demo 的具體實現(xiàn)可以參照 demo 的 Github 地址。
目前多線程編程的不足
目前只通過瀏覽器提供的 API 來進多線程開發(fā)的話成本非常大，主要有兩方面問題：
過于底層的 API
1.需要你實現(xiàn)語言級、或者系統(tǒng)級的 lock API，參照 Golang 的 lock API。
2.沒有語法上的支持，例如 Java synchronized 關(guān)鍵字等。
普通的 Javascript Object 無法共享
這其實也是 API 過于底層的另一方面的體現(xiàn)，也就是說對 JS 對象進行內(nèi)存共享的話，你需要開辟一段 SharedArrayBuffer，然后在此之上實現(xiàn)對 JS 對象的序列化、反序列化、更新等操作，實現(xiàn)成本也是比較大的。
事實上我們也不應該輕易手動實現(xiàn)相關(guān)的庫或者功能，因為相關(guān)領(lǐng)域的問題非常復雜、需要仔細的設計和實現(xiàn)。例如我們可以先使用下面這兩個庫：
- parlib-simple: 這個庫里面有類似于 Golang 里面 channel 一樣的 API。
- js-lock-and-condition: 這里庫有 Mutex 和 Cond 實現(xiàn)。
總結(jié)
瀏覽器提供給了我們進行多線程的能力，例如 PWA 或者 WebAseembly 與 JS 混用等場景都會用到上述的機制，如果你想實現(xiàn)一個高性能的網(wǎng)頁客戶端程序(例如 Figma 一樣的殺手級應用)，你最好也用上上述的機制。值得注意的是，用了鎖可能會降低你的程序的性能，具體要看線程切換和等待是的成本是否能夠抵消內(nèi)存拷貝的成本，例如 demo 完全可以改成無鎖的，代價將文件內(nèi)容拷貝到共享線程，并把工作線程的內(nèi)容拷貝回主線程。
雖然上面建議不要輕易實現(xiàn)自己的庫，例如上面的 lock 代碼短短幾行，但是其中的推導可以足夠?qū)懯畮醉摰?Paper 了，但是這里的基礎(chǔ)能力很匱乏，據(jù)筆者了解，TC39 提案中鮮少出現(xiàn)關(guān)于多線程編程的提案，目前僅發(fā)現(xiàn)以下這個：
- proposal-atomics-wait-async
但是，如果自信有能力和時間建設這些基礎(chǔ)能力的話，這個領(lǐng)域的確是“廣闊天地，大有作為”，特別是如果你的項目準備用 WebAseembly 和 JS 混用的情況(例如 Figma 就是用了 WebAssembly 和 React)。
