在 HarmonyOS 中，ArkTS 的多线程机制与传统 Java/C++ 的共享内存模型有本质区别。它采用的是基于 Actor 模型 的并发体系。
1. ArkTS 是否真正支持多线程？
结论：是真正的多线程，但不是“共享内存”的多线程。
- 并行执行：当你启动一个
Worker或向TaskPool发送任务时，系统确实会在后台开辟新的物理线程。这些线程与 UI 主线程并行运行，互不阻塞。 - 内存隔离：每个线程（Actor）都有自己独立的 ArkTS 引擎实例 和 独立堆内存。这意味着线程 A 里的变量，线程 B 在物理上是看不见的。这种设计彻底消除了“多线程锁（Lock）”带来的死锁和竞争风险，让并发开发变得极度安全。
2. Worker 之间是否可以直接访问变量？
结论：绝对不可以。
- 无法直接引用：你不能在一个线程里直接读取或修改另一个线程定义的全局变量或对象属性。
- 无全局共享空间：没有类似
window或global这种跨线程共享的内存区域。如果两个 Worker 需要通信，必须经过“中间人”（通常是主线程）进行中转，或者通过特定的通信协议发送消息。
3. 数据如何传递？
在“内存隔离”的大背景下，ArkTS 提供了三种数据传递方式，分别对应不同的性能需求：
A. 拷贝传输（Structured Clone）—— 最通用
这是默认方式。系统将对象序列化为二进制流，发送到目标线程后再反序列化还原。
- 特点：发送后，原对象和目标对象是两份独立的内存，修改互不影响。
- 缺点：传递超大对象（如 10MB 的 JSON）会有序列化耗时。
B. 转移传输（Transferable）—— 零拷贝
适用于 ArrayBuffer 等大数据。
- 特点：数据的所有权会从发送方“转移”给接收方。一旦发送，发送方将失去对该内存的访问权。
- 优点：零内存拷贝，极其高效。
C. 共享传输（SharedArrayBuffer & Sendable）—— 真正的共享
为了应对极高性能要求的场景，HarmonyOS 引入了特殊的共享机制：
-
SharedArrayBuffer：允许两个线程同时映射同一块物理内存。 -
@Sendable对象：这是 HarmonyOS NEXT 的核心特性。被标记为@Sendable的类，在跨线程传递时按引用传递（不拷贝，不转移所有权）。- 安全性：系统会通过特定的校验机制确保该对象在多线程并发读写时的安全性（通常配合
AsyncLock异步锁使用）。
- 安全性：系统会通过特定的校验机制确保该对象在多线程并发读写时的安全性（通常配合
总结：如何选择并发工具？
| 工具 | 场景建议 | 生命周期 |
|---|---|---|
| TaskPool | 首选。独立耗时任务（如文件压缩、数据计算）。 | 系统自动管理，执行完释放。 |
| Worker | 常驻任务（如 Socket 监听、持续的后台下载）。 | 开发者手动管理，需调用 terminate()。 |
一句话总结： ArkTS 用“隔离”换取了“安全”，又通过 @Sendable 为大型项目留下了性能后门。
