并發(fā)模型是用來實(shí)現(xiàn)不同應(yīng)用場景中并發(fā)任務(wù)的編程模型，通過合理地使用多線程，可以縮減應(yīng)用程序的開發(fā)和維護(hù)成本，同時(shí)還能更好地提升應(yīng)用程序在多核設(shè)備中的運(yùn)行性能。隨著IoT時(shí)代下應(yīng)用場景的不斷復(fù)雜、多核設(shè)備的不斷增多，并發(fā)模型顯得舉足輕重，本期我們將為大家?guī)矸街劬幾g器對傳統(tǒng)Actor并發(fā)模型的輕量級優(yōu)化。

一、什么是并發(fā)模型？

在操作系統(tǒng)中，并發(fā)是任務(wù)在不影響最終執(zhí)行結(jié)果的情況下無序或者按部分順序執(zhí)行的能力，如圖1所示，在一個(gè)時(shí)間段中可能有多個(gè)任務(wù)都處于已啟動運(yùn)行到運(yùn)行完畢之間，同時(shí)，并發(fā)單元也可以在多核設(shè)備下并行執(zhí)行，可以極大地提高多核設(shè)備的運(yùn)行性能。

圖1 并發(fā)單元的并行執(zhí)行

在日常開發(fā)中，由于并發(fā)任務(wù)多種多樣，任務(wù)拆分方式可能不同，線程間的通信方式也可能不同，所以不同場景下的多線程并發(fā)任務(wù)可以通過不同的并發(fā)編程模型來實(shí)現(xiàn)。常見的并發(fā)模型又分為內(nèi)存共享的并發(fā)模型和消息通信的并發(fā)模型。其中，基于內(nèi)存共享的并發(fā)模型存在數(shù)據(jù)競爭，往往需要鎖或者其它同步機(jī)制來保護(hù)共享的可變數(shù)據(jù)。而基于消息通信的并發(fā)模型，不需要開發(fā)者去面對鎖帶來的一系列復(fù)雜偶發(fā)的問題，同時(shí)并發(fā)度也相對較高。

作為基于消息通信并發(fā)模型的典型代表，Actor并發(fā)模型深受廣大開發(fā)者的追捧。下面，我們將為大家?guī)鞟ctor并發(fā)模型的解析。

二、Actor并發(fā)模型

Actor是一種歷史悠久的分布式并發(fā)模型，基于事件（消息）機(jī)制傳遞數(shù)據(jù)，能有效地避免線程中資源爭奪、死鎖等情況。本節(jié)我們將為大家介紹Actor并發(fā)模型的交互原理以及在JS中的應(yīng)用。

1. 交互原理

如圖2所示，在典型的Actor交互流程中，各個(gè)Actor并發(fā)地處理主線程任務(wù)，每個(gè)Actor內(nèi)部都有一個(gè)消息隊(duì)列及單線程執(zhí)行模塊，消息隊(duì)列負(fù)責(zé)接收主線程及其他Actor的請求，單線程執(zhí)行模塊則負(fù)責(zé)串行地處理請求、向其他Actor發(fā)送請求以及創(chuàng)建新的Actor。由于Actor采用的是異步方式，各個(gè)Actor之間相互隔離沒有數(shù)據(jù)競爭，因此Actor可以高并發(fā)運(yùn)行。

圖2 Actor交互流程

2. 應(yīng)用場景

Actor并發(fā)模型被廣泛應(yīng)用于Erlang、Haskell、Akka(Java)、JS等編程語言，下面我們將介紹Actor并發(fā)模型在JS中的應(yīng)用。

(1) Worker介紹

眾所周知，JS從誕生起就是單線程，為解決因單線程造成的I/O阻塞問題，JS通過異步回調(diào)的方式并結(jié)合事件機(jī)制，充分提高了單線程下對于輕量級事件的響應(yīng)速度。但是如果遇到某些比較復(fù)雜的任務(wù)，比如CPU密集型運(yùn)算任務(wù)、I/O密集型任務(wù)、同步任務(wù)等，仍采用單線程執(zhí)行就顯得有點(diǎn)力不從心，無法解決復(fù)雜任務(wù)的線程阻塞問題。所以，JS需要引入多線程任務(wù)支持。

Worker是較為典型的JS多線程解決方案，基于Actor并發(fā)模型實(shí)現(xiàn)，為JS創(chuàng)造多線程并發(fā)環(huán)境。如圖3所示，在Worker的交互流程中，JS主線程可以創(chuàng)建多個(gè)Worker子線程，各個(gè)Worker線程間相互隔離，并通過序列化傳遞對象，等到 Worker 線程完成計(jì)算任務(wù)，再把結(jié)果返回給主線程。

圖3 Worker交互流程

(2) Worker缺陷

Worker實(shí)現(xiàn)了復(fù)雜JS應(yīng)用的多線程并發(fā)執(zhí)行，在一定程度上提升了復(fù)雜JS應(yīng)用的運(yùn)行效率。但是，由于每個(gè)Worker線程都擁有獨(dú)立的虛擬機(jī)實(shí)例，且各個(gè)實(shí)例之間不共享任何數(shù)據(jù)，使得JS Worker啟動速度較慢、內(nèi)存占用較高。

三、Lite Actor

為了讓JS應(yīng)用能充分利用多核設(shè)備的計(jì)算能力更好地提升性能，方舟編譯器提出了Lite Actor概念，并針對Worker的缺陷進(jìn)行了優(yōu)化。

1.原理介紹

方舟編譯器JS運(yùn)行時(shí)在傳統(tǒng)Actor并發(fā)模型的基礎(chǔ)上，通過共享Actor實(shí)例中的不可變對象，以減少每個(gè)Actor實(shí)例承載的數(shù)據(jù)，提升了每個(gè)Actor的運(yùn)行性能，從而實(shí)現(xiàn)Actor并發(fā)模型的輕量級優(yōu)化。

圖4 Lite Actor

2. Worker優(yōu)化

方舟編譯器JS運(yùn)行時(shí)基于Lite Actor概念對Worker進(jìn)行了優(yōu)化，具體優(yōu)化如下：

●方舟編譯器JS運(yùn)行時(shí)通過內(nèi)置的字節(jié)碼文件管理器，已完成了對多個(gè)Worker間緩存的字節(jié)碼文件的共享，大大減少了字節(jié)碼的預(yù)加載處理時(shí)間以及內(nèi)存占用。

●方舟編譯器JS運(yùn)行時(shí)結(jié)合TS類型分析系統(tǒng)與對象分離技術(shù)，已經(jīng)實(shí)現(xiàn)了Worker中部分TS類型信息與準(zhǔn)靜態(tài)類型信息的識別與共享，在一定程度上減少Worker線程的內(nèi)存使用以及Worker線程間的信息傳遞耗時(shí)。同時(shí)，由于已共享的部分無需進(jìn)行序列化拷貝傳遞，所以Worker的序列化時(shí)長也得到了相應(yīng)的優(yōu)化。目前，剩余未共享部分?jǐn)?shù)據(jù)仍存在很大的提升空間，這部分工作仍會持續(xù)展開，讓我們共同期待。

●針對外部內(nèi)存的數(shù)據(jù)，例如字節(jié)碼中的字符串，由于不受JS內(nèi)存管理，未來也可以實(shí)現(xiàn)共享。

圖5 Worker優(yōu)化

3. 性能對比

使用方舟編譯器的Lite Actor優(yōu)化后，Worker的性能得到了顯著的增長，如圖6所示，不難看出，相較于傳統(tǒng)Actor并發(fā)模型，Worker的啟動時(shí)長及內(nèi)存占用均優(yōu)化了50%以上。

圖6 性能及內(nèi)存對比

以上就是本期全部內(nèi)容，方舟編譯器JS運(yùn)行時(shí)通過對傳統(tǒng)Actor并發(fā)模型的輕量級優(yōu)化，極大地提高了Worker的啟動性能。當(dāng)前Lite Actor仍有很大的探索空間，期待廣大開發(fā)者加入我們，共同見證萬物互聯(lián)的無限可能。

審核編輯：湯梓紅