Rust并发编程指南：Send/Sync、线程与异步编程最佳实践

m07-concurrency by zhanghandong/rust-skills

658 周安装量

912 GitHub Stars

GitHub

安装命令

npx skills add https://github.com/zhanghandong/rust-skills --skill m07-concurrency

系统架构性能优化 Rust

🇨🇳中文介绍

并发

第一层：语言机制

核心问题

这是 CPU 密集型还是 I/O 密集型任务，共享模型是什么？

在选择并发原语之前：

工作负载类型是什么？
需要共享哪些数据？
线程安全要求是什么？

错误 → 设计问题

错误	不要只是说	应该问
E0277 Send	"添加 Send 约束"	此类型是否需要跨线程？
E0277 Sync	"用 Mutex 包装"	真的需要共享访问吗？
Future not Send	"使用 spawn_local"	异步是正确的选择吗？
死锁	"重新排序锁"	锁的设计正确吗？

思考提示

在添加并发之前：

广告位招租

在这里展示您的产品或服务

触达数万 AI 开发者，精准高效

联系我们

相关 Skills

PostgreSQL表设计最佳实践：核心规则、数据类型选择与常见陷阱详解

9,600 周安装

Vue.js开发指南：最佳实践、组件设计与响应式编程核心原则

1,500 周安装

Flutter MVVM架构实现指南：可扩展应用开发与provider依赖注入

1,100 周安装

Vue.js Options API 最佳实践与 TypeScript 集成指南 - 解决常见开发问题

1,000 周安装

上下文关键词	加载领域技能	关键约束
Web API, HTTP, axum, actix, handler	domain-web	处理器可以在任何线程上运行
交易, 支付, trading, payment	domain-fintech	审计 + 线程安全
gRPC, kubernetes, microservice	domain-cloud-native	分布式追踪
CLI, terminal, clap	domain-cli	通常单线程即可

"Rc cannot be sent between threads" in Web API context
    ↑ DETECT: "Web API" → Load domain-web
    ↑ FIND: domain-web says "Shared state must be thread-safe"
    ↑ FIND: domain-web says "Rc in state" is Common Mistake
    ↓ DESIGN: Use Arc<T> with State extractor
    ↓ IMPL: axum::extract::State<Arc<AppConfig>>

情况	追溯到	问题
Web 中的 Send/Sync	domain-web	状态管理模式是什么？
CLI 中的 Send/Sync	domain-cli	真的需要多线程吗？
Mutex vs channels	m09-domain	共享状态还是消息传递？
Async vs threads	m10-performance	工作负载概况是什么？

"Need parallelism for CPU work"
    ↓ Use: std::thread or rayon

"Need concurrency for I/O"
    ↓ Use: async/await with tokio

"Need to share immutable data across threads"
    ↓ Use: Arc<T>

"Need to share mutable data across threads"
    ↓ Use: Arc<Mutex<T>> or Arc<RwLock<T>>
    ↓ Or: channels for message passing

"Need simple atomic operations"
    ↓ Use: AtomicBool, AtomicUsize, etc.

标记	含义	示例
`Send`	可以在线程间转移所有权	大多数类型
`Sync`	可以在线程间共享引用	`Arc<T>`
`!Send`	必须停留在单个线程	`Rc<T>`
`!Sync`	不能跨线程共享引用	`RefCell<T>`

模式	线程安全	阻塞	使用场景
`std::thread`	是	是	CPU 密集型并行
`async/await`	是	否	I/O 密集型并发
`Mutex<T>`	是	是	共享可变状态
`RwLock<T>`	是	是	读多写少的共享状态
`mpsc::channel`	是	可选	消息传递
`Arc<Mutex<T>>`	是	是	跨线程共享可变状态

What type of work?
├─ CPU-bound → std::thread or rayon
├─ I/O-bound → async/await
└─ Mixed → hybrid (spawn_blocking)

Need to share data?
├─ No → message passing (channels)
├─ Immutable → Arc<T>
└─ Mutable →
   ├─ Read-heavy → Arc<RwLock<T>>
   └─ Write-heavy → Arc<Mutex<T>>
   └─ Simple counter → AtomicUsize

Async context?
├─ Type is Send → tokio::spawn
├─ Type is !Send → spawn_local
└─ Blocking code → spawn_blocking

错误	原因	修复
E0277 `Send` 不满足	异步中使用非 Send 类型	使用 Arc 或 spawn_local
E0277 `Sync` 不满足	共享非 Sync 类型	用 Mutex 包装
死锁	锁顺序问题	保持一致的锁顺序
`future is not Send`	跨越 await 使用非 Send 类型	在 await 前释放
`MutexGuard` 跨越 await	挂起期间持有守卫	正确限定守卫作用域

反模式	为何不好	更好的做法
到处使用 Arc<Mutex>	争用，复杂性	消息传递
在异步中使用 thread::sleep	阻塞执行器	tokio::time::sleep
在 await 期间持有锁	阻塞其他任务	严格控制锁的作用域
忽略死锁风险	难以调试	锁顺序，try_lock

何时	查看
智能指针选择	m02-resource
内部可变性	m03-mutability
性能调优	m10-performance
领域并发需求	domain-*

🇺🇸English

Concurrency

Layer 1: Language Mechanics

Core Question

Is this CPU-bound or I/O-bound, and what's the sharing model?

Before choosing concurrency primitives:

What's the workload type?
What data needs to be shared?
What's the thread safety requirement?

Error → Design Question

Error	Don't Just Say	Ask Instead
E0277 Send	"Add Send bound"	Should this type cross threads?
E0277 Sync	"Wrap in Mutex"	Is shared access really needed?
Future not Send	"Use spawn_local"	Is async the right choice?
Deadlock	"Reorder locks"	Is the locking design correct?

Thinking Prompt

Before adding concurrency:

What's the workload?
- CPU-bound → threads (std::thread, rayon)
- I/O-bound → async (tokio, async-std)
- Mixed → hybrid approach
What's the sharing model?
- No sharing → message passing (channels)
- Immutable sharing → Arc
- Mutable sharing → Arc<Mutex> or Arc<RwLock>
What are the Send/Sync requirements?
- Cross-thread ownership → Send
- Cross-thread references → Sync
- Single-thread async → spawn_local

Trace Up ↑ (MANDATORY)

CRITICAL : Don't just fix the error. Trace UP to find domain constraints.

Domain Detection Table

Context Keywords	Load Domain Skill	Key Constraint
Web API, HTTP, axum, actix, handler	domain-web	Handlers run on any thread
交易, 支付, trading, payment	domain-fintech	Audit + thread safety
gRPC, kubernetes, microservice	domain-cloud-native	Distributed tracing
CLI, terminal, clap	domain-cli	Usually single-thread OK

Example: Web API + Rc Error

"Rc cannot be sent between threads" in Web API context
    ↑ DETECT: "Web API" → Load domain-web
    ↑ FIND: domain-web says "Shared state must be thread-safe"
    ↑ FIND: domain-web says "Rc in state" is Common Mistake
    ↓ DESIGN: Use Arc<T> with State extractor
    ↓ IMPL: axum::extract::State<Arc<AppConfig>>

Generic Trace

"Send not satisfied for my type"
    ↑ Ask: What domain is this? Load domain-* skill
    ↑ Ask: Does this type need to cross thread boundaries?
    ↑ Check: m09-domain (is the data model correct?)

Situation	Trace To	Question
Send/Sync in Web	domain-web	What's the state management pattern?
Send/Sync in CLI	domain-cli	Is multi-thread really needed?
Mutex vs channels	m09-domain	Shared state or message passing?
Async vs threads	m10-performance	What's the workload profile?

Trace Down ↓

From design to implementation:

"Need parallelism for CPU work"
    ↓ Use: std::thread or rayon

"Need concurrency for I/O"
    ↓ Use: async/await with tokio

"Need to share immutable data across threads"
    ↓ Use: Arc<T>

"Need to share mutable data across threads"
    ↓ Use: Arc<Mutex<T>> or Arc<RwLock<T>>
    ↓ Or: channels for message passing

"Need simple atomic operations"
    ↓ Use: AtomicBool, AtomicUsize, etc.

Send/Sync Markers

Marker	Meaning	Example
`Send`	Can transfer ownership between threads	Most types
`Sync`	Can share references between threads	`Arc<T>`
`!Send`	Must stay on one thread	`Rc<T>`
`!Sync`	No shared refs across threads

Quick Reference

Pattern	Thread-Safe	Blocking	Use When
`std::thread`	Yes	Yes	CPU-bound parallelism
`async/await`	Yes	No	I/O-bound concurrency
`Mutex<T>`	Yes	Yes	Shared mutable state
`RwLock<T>`	Yes	Yes	Read-heavy shared state

Decision Flowchart

What type of work?
├─ CPU-bound → std::thread or rayon
├─ I/O-bound → async/await
└─ Mixed → hybrid (spawn_blocking)

Need to share data?
├─ No → message passing (channels)
├─ Immutable → Arc<T>
└─ Mutable →
   ├─ Read-heavy → Arc<RwLock<T>>
   └─ Write-heavy → Arc<Mutex<T>>
   └─ Simple counter → AtomicUsize

Async context?
├─ Type is Send → tokio::spawn
├─ Type is !Send → spawn_local
└─ Blocking code → spawn_blocking

Common Errors

Error	Cause	Fix
E0277 `Send` not satisfied	Non-Send in async	Use Arc or spawn_local
E0277 `Sync` not satisfied	Non-Sync shared	Wrap with Mutex
Deadlock	Lock ordering	Consistent lock order
`future is not Send`	Non-Send across await	Drop before await
`MutexGuard` across await	Guard held during suspend	Scope guard properly

Anti-Patterns

Anti-Pattern	Why Bad	Better
Arc<Mutex> everywhere	Contention, complexity	Message passing
thread::sleep in async	Blocks executor	tokio::time::sleep
Holding locks across await	Blocks other tasks	Scope locks tightly
Ignoring deadlock risk	Hard to debug	Lock ordering, try_lock

Async-Specific Patterns

Avoid MutexGuard Across Await

// Bad: guard held across await
let guard = mutex.lock().await;
do_async().await;  // guard still held!

// Good: scope the lock
{
    let guard = mutex.lock().await;
    // use guard
}  // guard dropped
do_async().await;

Non-Send Types in Async

// Rc is !Send, can't cross await in spawned task
// Option 1: use Arc instead
// Option 2: use spawn_local (single-thread runtime)
// Option 3: ensure Rc is dropped before .await

Related Skills

When	See
Smart pointer choice	m02-resource
Interior mutability	m03-mutability
Performance tuning	m10-performance
Domain concurrency needs	domain-*

Weekly Installs

658

Repository

zhanghandong/rust-skills

GitHub Stars

912

First Seen

Jan 20, 2026

Security Audits

Gen Agent Trust HubPass SocketPass SnykPass

Installed on

opencode604

codex586

gemini-cli573

github-copilot560

amp497

kimi-cli495

Rust并发编程指南：Send/Sync、线程与异步编程最佳实践

🇨🇳中文介绍

并发

核心问题

错误 → 设计问题

思考提示

相关 Skills

向上追溯 ↑ (强制)

领域检测表

示例：Web API + Rc 错误

通用追溯

向下追溯 ↓

Send/Sync 标记

快速参考

决策流程图

常见错误

反模式

异步特定模式

避免 MutexGuard 跨越 Await

异步中的非 Send 类型

相关技能