首先明確一點(diǎn)ArkTS是單線程模型攻泼，底層線程模型對(duì)接了libuv。在應(yīng)用進(jìn)程啟動(dòng)后诡延，會(huì)有多個(gè)I/O線程用于I/O操作滞欠。JS線程的I/O異步操作，會(huì)在I/O線程執(zhí)行肆良，JS線程可以同時(shí)執(zhí)行其他操作筛璧，不存在阻塞等待問(wèn)題逸绎。
多線程數(shù)據(jù)共享
大部分普通對(duì)象跨線程均采用序列化方式，線程間對(duì)象的數(shù)據(jù)通信依賴序列化夭谤、反序列化棺牧，耗時(shí)與數(shù)據(jù)量相關(guān)，需要控制傳輸?shù)臄?shù)據(jù)量沮翔。也可采用通過(guò)ArrayBuffer的轉(zhuǎn)移傳輸和SharedArrayBuffer進(jìn)行共享陨帆。-
大量線程并發(fā)方案
當(dāng)前ArkTS提供了TaskPool和Worker兩種并發(fā)能力曲秉，TaskPool和Worker都基于Actor并發(fā)模型實(shí)現(xiàn)采蚀。大量線程并發(fā)時(shí)- 將多線程任務(wù)轉(zhuǎn)變?yōu)椴l(fā)任務(wù)，通過(guò)TaskPool分發(fā)執(zhí)行承二。
- I/O型任務(wù)不需要單獨(dú)開(kāi)啟線程榆鼠，而是在當(dāng)前線程（可以是TaskPool線程）執(zhí)行。
- 少量需要常駐的CPU密集型任務(wù)亥鸠，采用Worker妆够，并且需要控制在64個(gè)及以下。
-
TaskPool和Worker
不同點(diǎn)：兩者是不同顆粒度的并發(fā)API负蚊，Worker更像Thread或者Service維度神妹，Task就是單一任務(wù)維度。同時(shí)TaskPool簡(jiǎn)化開(kāi)發(fā)者開(kāi)發(fā)并發(fā)程序家妆，支持優(yōu)先級(jí)和取消鸵荠，并且通過(guò)統(tǒng)一管理節(jié)省系統(tǒng)資源優(yōu)化調(diào)度。
相同點(diǎn)：在JS相關(guān)的線程間交互上伤极，二者本質(zhì)都是內(nèi)存隔離模型蛹找，參數(shù)與范圍值的限制是一致的，也有開(kāi)銷哨坪。
調(diào)度機(jī)制：
TaskPool與Worker采用事件循環(huán)接收線程間通信的消息庸疾。數(shù)量、優(yōu)先級(jí)
TaskPool內(nèi)部會(huì)動(dòng)態(tài)調(diào)整線程個(gè)數(shù)当编，不支持設(shè)置數(shù)量届慈，只需要往線程池中拋任務(wù)，確保高優(yōu)先級(jí)任務(wù)的及時(shí)執(zhí)行忿偷。
Worker的線程個(gè)數(shù)最多64個(gè)金顿，如果Worker超過(guò)規(guī)定個(gè)數(shù)，會(huì)創(chuàng)建失敗牵舱。
TaskPool與Worker兩者獨(dú)立串绩，不相互影響，因此Worker在達(dá)到上限數(shù)量時(shí)芜壁，不會(huì)影響TaskPool線程安全
ArkTS的多線程是基于事件共享實(shí)現(xiàn)的礁凡，其數(shù)據(jù)交換是基于事件進(jìn)行傳遞對(duì)象高氮，所以不存在線程安全的問(wèn)題。
ArkTS語(yǔ)言基礎(chǔ)類庫(kù)提供的taskPool和worker兩個(gè)多線程的方案顷牌，都是基于Actor并發(fā)模型實(shí)現(xiàn)的剪芍。Actor并發(fā)模型是基于事件基礎(chǔ)傳遞數(shù)據(jù)，不需要開(kāi)發(fā)者去面對(duì)鎖帶來(lái)的一系列復(fù)雜偶發(fā)的問(wèn)題窟蓝，是線程安全的罪裹，同時(shí)并發(fā)度也相對(duì)較高。目前線程間的數(shù)據(jù)傳輸支持的對(duì)象分為三類运挫，普通的JavaScript對(duì)象状共，可轉(zhuǎn)移對(duì)象，可共享對(duì)象谁帕。
參考：
使用多線程并發(fā)能力進(jìn)行開(kāi)發(fā)
ArkTS線程模型和并發(fā)
多線程方案如何保證線程安全
