演講嘉賓 | 李勇彪

回顧整理 | 廖 濤

排版校對(duì) | 李萍萍

嘉賓簡(jiǎn)介

李勇彪，OpenHarmony項(xiàng)目群技術(shù)指導(dǎo)委員會(huì)編程語(yǔ)言TSG成員，華為OpenHarmony虛擬機(jī)編譯器專家。2021年至今，華為終端OS語(yǔ)言編譯運(yùn)行時(shí)團(tuán)隊(duì)架構(gòu)師，負(fù)責(zé)OpenHarmony高級(jí)語(yǔ)言編譯運(yùn)行時(shí)的整體技術(shù)架構(gòu)。曾就職于阿里巴巴，參與并主導(dǎo)AliOS高級(jí)語(yǔ)言虛擬機(jī)的編譯優(yōu)化、內(nèi)存管理優(yōu)化、多線程優(yōu)化等項(xiàng)目。目前聚焦在移動(dòng)OS的編程語(yǔ)言及語(yǔ)言虛擬機(jī)領(lǐng)域。

內(nèi)容來(lái)源

第一屆開(kāi)放原子開(kāi)源基金會(huì)OpenHarmony技術(shù)峰會(huì)——編程語(yǔ)言及應(yīng)用框架分論壇

正 文 內(nèi) 容

隨著摩爾定律放緩現(xiàn)象的日益突出以及計(jì)算機(jī)多核系統(tǒng)架構(gòu)的出現(xiàn)，并發(fā)編程持續(xù)引起了廣泛的關(guān)注。目前，移動(dòng)應(yīng)用領(lǐng)域的并發(fā)探索有哪些，在OpenHarmony上又有哪些成果和未來(lái)規(guī)劃呢？華為終端編譯器與運(yùn)行時(shí)架構(gòu)師李勇彪在第一屆OpenHarmony技術(shù)峰會(huì)上給大家?guī)?lái)了幾點(diǎn)分享。

01?

并發(fā)的背景

摩爾定律由Intel的聯(lián)合創(chuàng)始人兼前CEO戈登·摩爾提出，即半導(dǎo)體芯片上集成的晶體管和電阻數(shù)量將每?jī)赡暝黾右槐叮?a target="_blank">微處理器的性能提高一倍，或價(jià)格下降一半。在過(guò)去的幾十年間，摩爾定律為算力乃至生產(chǎn)力的發(fā)展作出了巨大的貢獻(xiàn)，但至2022年，隨著Denard微縮效應(yīng)遇到了元件物理的瓶頸，業(yè)界逐漸對(duì)這一觀點(diǎn)產(chǎn)生了強(qiáng)烈的分歧，一部分人士認(rèn)為摩爾定律正在逐步放緩甚至有失效的傾向，另一部分人士認(rèn)為摩爾定律仍然有效，僅是成本增加了。在該背景下，單芯片功耗約束了單核的性能，基于多核化的并發(fā)編程成為移動(dòng)領(lǐng)域提升性能的重要技術(shù)手段。

摩爾定律放緩現(xiàn)象

那么，什么是并發(fā)呢？并發(fā)指同一時(shí)間應(yīng)對(duì)多項(xiàng)任務(wù)的能力，一個(gè)時(shí)間段中有幾個(gè)任務(wù)都處于運(yùn)行準(zhǔn)備就緒狀態(tài)，在單核設(shè)備中，任一個(gè)時(shí)刻只有一個(gè)任務(wù)能夠運(yùn)行，其運(yùn)行順序是不固定的；而在多核場(chǎng)景中，同一時(shí)間可以多項(xiàng)任務(wù)并行。

并發(fā)與并行

02?

常見(jiàn)的并發(fā)模型

2.1??

線程和鎖

線程和鎖是并發(fā)模型的一種常見(jiàn)表示，下圖示意了一種典型的CPU多核架構(gòu)，可以看出，L3 Cache在多核間共享，因此L3 Cache的一致性是保證程序在多核間正常運(yùn)行的基礎(chǔ)。在確保單線程執(zhí)行結(jié)果不變的前提下，可以做任意編譯器優(yōu)化，如常量傳播、公共子表達(dá)式消除、內(nèi)聯(lián)、標(biāo)量替換、死代碼刪除、指令亂序等。由于不同的操作系統(tǒng)對(duì)內(nèi)存一致性有不同的約束，需要通使用鎖等同步語(yǔ)義保證多線程內(nèi)存一致性。目前，通過(guò)基于共享內(nèi)存的樂(lè)觀鎖、自旋鎖、偏向鎖、精準(zhǔn)內(nèi)存屏障等手段可以實(shí)現(xiàn)性能優(yōu)秀的多線程程序，但也存在一定的問(wèn)題：線程和鎖方案的優(yōu)化依賴軟件工程有良好的并發(fā)實(shí)踐規(guī)范和資深并發(fā)程序開(kāi)發(fā)者，且容易引發(fā)死鎖，測(cè)試及維護(hù)的成本也很高。

一種 CPU 多核架構(gòu)

2.2??

Actor 模型

Actor模型概念的提出已經(jīng)幾十年了：一個(gè)actor是一個(gè)基本的計(jì)算單元，通過(guò)消息通信；內(nèi)部維持可變狀態(tài)，兩邊互相不能直接修改。其優(yōu)勢(shì)在于每個(gè)Actor易于維護(hù)以及測(cè)試，業(yè)務(wù)開(kāi)發(fā)只需要關(guān)心業(yè)務(wù)的消息處理，測(cè)試只需要覆蓋消息流順序即可。此外，其容錯(cuò)性也好，適合分布式編程。當(dāng)然，Actor模型也存在一定的短板：存在信箱堆滿問(wèn)題，不共享狀態(tài)，只通過(guò)消息通信交互，不適合細(xì)粒度并行。

Actor 模型

2.3??

函數(shù)式編程

函數(shù)式編程有以下特點(diǎn)：函數(shù)是一等公民；無(wú)副作用（無(wú)共享可變狀態(tài)）；純函數(shù)構(gòu)建一切。在函數(shù)式編程下，只要輸入一定，其輸出也一定符合預(yù)期。真實(shí)世界的函數(shù)式則更依賴參數(shù)化，會(huì)將函數(shù)副作用（Side Effect）上拋，盡量脫離開(kāi)發(fā)者編寫(xiě)的業(yè)務(wù)邏輯層，在框架內(nèi)部進(jìn)行處理，且有結(jié)構(gòu)依賴。該模式具有確定性、健壯性（易維護(hù)易測(cè)試）以及天然支持并行化等優(yōu)勢(shì)，但開(kāi)發(fā)效率較低，實(shí)際的業(yè)務(wù)邏輯很難直接轉(zhuǎn)成函數(shù)式開(kāi)發(fā)，且在部分場(chǎng)景下性能表現(xiàn)較差。

函數(shù)式編程

2.4??

并發(fā)模型特點(diǎn)

常見(jiàn)的并發(fā)模型主要分為兩類，一類僅基于共享內(nèi)存，另一類則基于消息通信。基于共享內(nèi)存的并發(fā)模型（線程與鎖），具有適用范圍廣、接近硬件工作方式的本質(zhì)和正確使用時(shí)效率很高的優(yōu)勢(shì)，但不可避免地存在測(cè)試及維護(hù)困難等問(wèn)題，目前該模式已經(jīng)逐漸被應(yīng)用開(kāi)發(fā)領(lǐng)域摒棄；基于消息通信的并發(fā)模型（Actor、函數(shù)式編程），具有容錯(cuò)性好、特定場(chǎng)景性能表現(xiàn)很好且易于維護(hù)和測(cè)試的優(yōu)勢(shì)，但也存在應(yīng)用場(chǎng)景有限、不適合細(xì)粒度并行等短板。

03?

移動(dòng)應(yīng)用框架并發(fā)

3.1??

Dart 語(yǔ)言

Dart是一門新的編程語(yǔ)言，如同JAVA、PHP一樣，是為了解決編寫(xiě)應(yīng)用程序中的一些實(shí)際問(wèn)題而被Google發(fā)明的，其早期主要是為了能夠在Web領(lǐng)域替換JavaScript（后文簡(jiǎn)稱JS），后來(lái)Google內(nèi)部用Dart編寫(xiě)孵化了一個(gè)移動(dòng)開(kāi)發(fā)框架Sky，之后又被命名為Flutter，在移動(dòng)跨平臺(tái)開(kāi)發(fā)領(lǐng)域大放異彩。Dart的并發(fā)目標(biāo)主要為了賦能框架支持任務(wù)并行化，解決開(kāi)發(fā)者的并發(fā)任務(wù)和多線程開(kāi)發(fā)需求。其僅共享不可變對(duì)象，而可變對(duì)象不共享，且提供了單線程并發(fā)（異步）和多線程并發(fā)（Isolate Spawn /Compute）的并發(fā)API。

Dart 并發(fā)架構(gòu)

3.2??

Swift

Swift是蘋(píng)果公司于2014年WWDC蘋(píng)果開(kāi)發(fā)者大會(huì)發(fā)布的新開(kāi)發(fā)語(yǔ)言，可與Objective-C共同運(yùn)行于macOS和iOS平臺(tái)，用于搭建基于蘋(píng)果平臺(tái)的應(yīng)用程序。在2022年的Swift 5.5版本中，發(fā)布了并發(fā)API的說(shuō)明，其并發(fā)目標(biāo)主要為了減少應(yīng)用開(kāi)發(fā)者從想法到實(shí)現(xiàn)必須花費(fèi)的時(shí)間，使體驗(yàn)遠(yuǎn)遠(yuǎn)優(yōu)于現(xiàn)有方案（隊(duì)列不可知、可維護(hù)性差且安全性低）。Swift的并發(fā)理念是，共享可變狀態(tài)不利于開(kāi)發(fā)者，也不利于硬件，且無(wú)法突破單進(jìn)程。因此，Swift希望能夠提供無(wú)損化的易用的API，在設(shè)計(jì)、可維護(hù)性、安全性、可伸縮性以及性能等方面持續(xù)改進(jìn)。目前，Swift已提供的API有async/await、Task & TaskGroup、Actor等。

3.3??

流行移動(dòng)操作系統(tǒng)并發(fā)模型趨勢(shì)

在移動(dòng)應(yīng)用開(kāi)發(fā)領(lǐng)域中，迭代和更新頻繁，開(kāi)發(fā)效率是一個(gè)關(guān)鍵因素，而鎖對(duì)于應(yīng)用開(kāi)發(fā)者過(guò)于底層，很難用好，難以調(diào)試，屬于高級(jí)用法。出于提供易用、簡(jiǎn)單、高效的并發(fā)模型考慮，業(yè)界目前給應(yīng)用開(kāi)發(fā)者提供的多線程模型，有避免數(shù)據(jù)競(jìng)爭(zhēng)、實(shí)現(xiàn)無(wú)鎖化的趨勢(shì)。例如，在Web上，JS在多線程使用的是消息通信機(jī)制（內(nèi)存隔離，增加可轉(zhuǎn)移Builtin對(duì)象支持）；在Flutter上，Dart在多線程使用的是消息通信機(jī)制 (內(nèi)存隔離)；在Android上，Kotlin原生先后提出過(guò)Worker API、不可變共享、對(duì)象轉(zhuǎn)移凍結(jié)等方案替換共享多線程方案（用戶不使用鎖）；在IOS上，Swift 5.5實(shí)現(xiàn)了結(jié)構(gòu)化編程和Actor，Swift整體并發(fā)的演進(jìn)思路是默認(rèn)安全的編程模型。

04?

OpenHarmony高級(jí)語(yǔ)言的并發(fā)探索

在JS世界的并發(fā)中，如前文所提到的JS并發(fā)架構(gòu)—Actor模型，具有無(wú)鎖、容易維護(hù)和測(cè)試、容錯(cuò)性好以及分布式編程等優(yōu)勢(shì)，但啟動(dòng)較慢，并發(fā)的實(shí)例開(kāi)銷大。對(duì)于JS并發(fā)API—Worker來(lái)說(shuō)，由于其每一個(gè)并發(fā)實(shí)例之間不共享，開(kāi)發(fā)者需要封裝和解析消息命令，關(guān)心Worker實(shí)例的生命周期，在高負(fù)載和低負(fù)載時(shí)也需要精確調(diào)節(jié)Worker數(shù)量。

基于上述問(wèn)題，OpenHarmony上實(shí)現(xiàn)了輕量化并發(fā)實(shí)例——Lite Actor。該功能支持不可變對(duì)象共享，對(duì)基礎(chǔ)架構(gòu)進(jìn)行了輕量化處理，大幅提升了啟動(dòng)時(shí)間，且優(yōu)化了啟動(dòng)內(nèi)存。

ArkCompiler并發(fā)實(shí)例運(yùn)行

OpenHarmony也提供了TaskPool。TaskPool是一個(gè)更易用的并發(fā)任務(wù)API，能夠使開(kāi)發(fā)者易于開(kāi)發(fā)并發(fā)任務(wù)，減少代碼編寫(xiě)量，讓其無(wú)需關(guān)心并發(fā)實(shí)例的生命周期和場(chǎng)景下并發(fā)任務(wù)的負(fù)載輕重。此外，TaskPool還能夠統(tǒng)一任務(wù)負(fù)載的資源管理，降低了系統(tǒng)的資源消耗，提升了系統(tǒng)的整體性能。在如圖所示的TaskPool架構(gòu)中，通過(guò)Task Dispatch Manager實(shí)現(xiàn)優(yōu)先級(jí)調(diào)度、負(fù)載均衡以及系統(tǒng)的統(tǒng)一管理等功能，通過(guò)Task Worker Threads實(shí)現(xiàn)自適應(yīng)性和可伸縮性。

TaskPool統(tǒng)一任務(wù)池設(shè)計(jì)架構(gòu)

在高級(jí)語(yǔ)言并發(fā)的發(fā)展中，業(yè)界更傾向于給開(kāi)發(fā)者提供更易用、更好用以及更高效的并發(fā)API。OpenHarmony提供的并發(fā)API目前介于Dart和Swift之間，汲取兩者的長(zhǎng)處，并對(duì)其現(xiàn)存問(wèn)題進(jìn)行持續(xù)的優(yōu)化和改進(jìn)。此外，OpenHarmony正在考慮引入準(zhǔn)靜態(tài)對(duì)象，實(shí)現(xiàn)真正共享。

05?

總結(jié)

在OpenHarmony并發(fā)模型上，后續(xù)將對(duì)并發(fā)實(shí)例進(jìn)一步輕量化，探索共享對(duì)象的無(wú)鎖并發(fā)。此外，在OpenHarmony并發(fā)調(diào)度上，也將針對(duì)現(xiàn)存的系統(tǒng)中線程泛濫問(wèn)題，從時(shí)間和空間兩個(gè)維度設(shè)計(jì)相關(guān)方案進(jìn)行優(yōu)化和改進(jìn)，并將開(kāi)發(fā)一套統(tǒng)一的并行框架，在運(yùn)行時(shí)根據(jù)任務(wù)依賴狀態(tài)和可執(zhí)行資源自動(dòng)并發(fā)調(diào)度和執(zhí)行任務(wù)。

歡迎大家持續(xù)關(guān)注OpenHarmony并發(fā)研究工作，也期待與社區(qū)的開(kāi)發(fā)者們共建OpenHarmony的并發(fā)能力。

E N D