并发安全的概念以及解决

发表于 分类于 阅读次数： 本文字数： 5.8k 阅读时长 ≈ 5 分钟

要理解并发安全，首先需要明确 “并发” 的场景，再剖析 “安全” 的核心诉求 —— 最终本质是解决 “多任务共享资源时的正确性问题”。

一、先搞懂：什么是 “并发”？

并发（Concurrency）是指多个任务在同一时间段内 “交替执行” 或 “看似同时执行” 的场景，常见于计算机程序中（比如：你的手机同时运行微信、音乐 APP、导航；服务器同时处理 1000 个用户的请求）。

实现并发的核心载体通常是线程（Thread）或进程（Process）：

  • 进程：程序的独立运行实例（如微信是一个进程，音乐 APP 是另一个进程），进程间资源默认隔离。
  • 线程：进程内的 “轻量级执行单元”（如微信内 “接收消息”“刷新朋友圈” 是两个线程），线程间共享进程的资源（如内存中的变量、文件句柄等）。

正因为线程间共享资源，才会出现 “并发不安全” 的问题。

二、核心定义：什么是 “并发安全”？

当多个线程同时操作（读 / 写）同一份 “共享资源” 时，无论线程的执行顺序如何交替，最终程序的执行结果始终符合 “预期逻辑”，且不会出现数据损坏、逻辑错乱等问题 —— 这种特性就是 “并发安全”。

反过来，“并发不安全” 的典型表现是：

  • 数据计算错误（如计数器少加、金额计算偏差）；
  • 数据状态不一致（如订单状态既显示 “已支付” 又显示 “未支付”）；
  • 程序崩溃（如数组越界、空指针异常）。

三、关键原因：为什么会 “并发不安全”？

根源是 “共享资源的非原子操作”+“线程执行顺序不可控”，这两个条件叠加会导致 “竞态条件（Race Condition）”—— 即线程的执行结果依赖于 “线程执行的先后顺序”，从而出现不可预期的错误。

用一个经典例子理解：多线程操作计数器
假设我们有一个共享变量 count = 0，两个线程同时执行 “count += 1”（预期最终结果是 2）。但 “count += 1” 看似简单，实际在计算机中需要 3 步非原子操作：

  1. 读取：线程从内存中读取 count 的当前值（0）到 CPU 寄存器；
  2. 计算：CPU 寄存器中执行 “0 + 1 = 1”；
  3. 写入：将计算结果（1）写回内存的 count 中。

由于线程执行顺序是操作系统调度的（不可控），可能出现以下错乱：

  • 线程 A 执行步骤 1（读 0）→ 被操作系统暂停；
  • 线程 B 执行步骤 1（读 0）→ 步骤 2（算 1）→ 步骤 3（写回 1，此时 count=1）；
  • 线程 A 恢复执行，继续步骤 2（算 1）→ 步骤 3（写回 1，此时 count=1）。

最终 count=1（而非预期的 2）—— 这就是 “并发不安全” 的典型结果。

四、如何实现 “并发安全”？核心思路：消除竞态条件

解决并发安全的核心是控制 “共享资源的访问顺序”，确保同一时间只有一个（或符合规则的多个）线程能操作共享资源。常见方案有 3 类：

1. 锁机制：“独占访问”，最常用

通过 “锁” 将 “非原子操作” 变成 “原子操作”（即操作要么全执行，要么全不执行，中间不会被其他线程打断）。

锁类型 核心逻辑 适用场景
互斥锁（Mutex） “一人占用，其他人等待”：同一时间只有一个线程能获取锁，执行临界区代码。 读、写操作都频繁的场景
读写锁（RWMutex） “读共享，写独占”：多个线程可同时读；但写线程获取锁时，所有读 / 写线程都需等。 读操作远多于写操作的场景（如缓存）
自旋锁（Spinlock） 线程获取锁失败时不阻塞，而是循环重试（“自旋”），减少线程切换开销。 临界区代码执行时间极短的场景

示例（伪代码）：用互斥锁保护计数器

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
import threading

count = 0
lock = threading.Lock()  # 创建互斥锁

def add_one():
    global count
    with lock:  # 自动获取锁，代码块执行完自动释放
        # 以下3步操作被“原子化”，不会被其他线程打断
        temp = count
        temp += 1
        count = temp

# 启动两个线程执行add_one
t1 = threading.Thread(target=add_one)
t2 = threading.Thread(target=add_one)
t1.start()
t2.start()
t1.join()
t2.join()

print(count)  # 结果稳定为2，实现并发安全

2. 原子操作：CPU 级别的 “不可打断”

对于简单的操作（如整数加减、赋值），可以直接使用 CPU 提供的 “原子指令”（如 x86 的INC、XADD指令），无需手动加锁 —— 这些指令在硬件层面保证 “执行过程不会被打断”。

主流编程语言都封装了原子操作 API，例如：

  • Java：java.util.concurrent.atomic.AtomicInteger
  • Go：sync/atomic包的AddInt64、LoadInt32等
  • C++：std::atomic模板类

示例（Java）：用原子类实现计数器

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
import java.util.concurrent.atomic.AtomicInteger;

public class AtomicDemo {
    private static AtomicInteger count = new AtomicInteger(0);

    public static void main(String[] args) throws InterruptedException {
        // 两个线程同时调用incrementAndGet（原子加1）
        Thread t1 = new Thread(() -> count.incrementAndGet());
        Thread t2 = new Thread(() -> count.incrementAndGet());
        t1.start();
        t2.start();
        t1.join();
        t2.join();
        System.out.println(count);  // 结果稳定为2
    }
}

3. 无锁编程：避免共享，从根源消除问题

如果能让线程 “不共享资源”，自然就不会有并发安全问题。常见思路：

  • 线程本地存储（Thread Local）：为每个线程分配独立的 “私有资源”，而非共享一个资源。例如：Java 的ThreadLocal，每个线程读写自己的ThreadLocal变量，互不干扰。
  • 不可变对象（Immutable Object）：共享资源一旦创建就无法修改（如 Java 的String、Go 的string）。多个线程只能 “读”，不能 “写”，因此不会出现竞争。

五、易混淆概念：并发安全 vs 线程安全

很多时候 “并发安全” 和 “线程安全（Thread Safety）” 会被混用，但两者有细微区别：

  • 线程安全：特指 “多线程共享资源时的正确性”，是并发安全的子集（因为并发还包括 “多进程并发”“协程并发” 等场景）。
  • 并发安全：范围更广，涵盖所有并发场景（线程、进程、协程等）的资源访问正确性。

日常开发中，若场景是 “多线程”，两者可近似等价。

六、关键提醒：不是所有并发都需要 “安全”

只有当 “多个任务共享资源且存在写操作” 时，才需要考虑并发安全。如果满足以下条件，无需处理：

  • 资源不共享（如每个线程用自己的局部变量）；
  • 共享资源只有读操作（无写操作，如多线程读同一个配置文件）。

盲目加锁会增加 “线程切换开销”“锁竞争开销”，反而降低程序性能 —— 并发安全的核心是 “在正确性和性能间找平衡”。

总结

并发安全的本质是：在多任务共享资源的场景下，通过控制资源访问顺序（锁、原子操作等），确保程序结果始终符合预期，避免竞态条件导致的错误。理解它的关键是抓住 “共享资源” 和 “非原子操作” 这两个核心矛盾，再针对性选择解决方案。

在 Go 语言及 GoFrame 框架中实现count+1的并发安全，可以利用 Go 原生的并发控制机制或 GoFrame 封装的工具，核心思路仍是避免竞态条件。以下是具体实现方式：

一、Go 语言原生实现（无框架依赖）

Go 语言标准库提供了两种常用方案：互斥锁（sync.Mutex） 和原子操作（sync/atomic），适用于不同场景。

1. 互斥锁（sync.Mutex）：通用方案

适合复杂逻辑的临界区保护（不仅限于count+1，还可包含更多业务代码）。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
package main

import (
	"fmt"
	"sync"
)

func main() {
	var count int
	var mu sync.Mutex // 声明互斥锁
	var wg sync.WaitGroup // 用于等待所有线程完成

	// 启动1000个goroutine同时执行count+1
	for i := 0; i < 1000; i++ {
		wg.Add(1)
		go func() {
			defer wg.Done()
			mu.Lock()   // 获取锁：进入临界区前加锁
			count++     // 安全执行count+1
			mu.Unlock() // 释放锁：离开临界区后解锁
		}()
	}

	wg.Wait() // 等待所有goroutine执行完毕
	fmt.Println("最终count值：", count) // 稳定输出1000
}

关键点：

  • mu.Lock() 和 mu.Unlock() 之间的代码为 “临界区”，同一时间只有一个 goroutine 能执行，确保count++的原子性。
  • 必须在defer或函数退出前释放锁，避免死锁。

2. 原子操作（sync/atomic）：高性能方案

适合简单的数值增减（如计数器），由 CPU 提供硬件级原子性保证，性能优于锁。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
package main

import (
	"fmt"
	"sync"
	"sync/atomic"
)

func main() {
	var count int64 // 注意：atomic操作要求变量为int32/int64等特定类型
	var wg sync.WaitGroup

	// 启动1000个goroutine同时执行count+1
	for i := 0; i < 1000; i++ {
		wg.Add(1)
		go func() {
			defer wg.Done()
			// 原子操作：count += 1，返回操作后的值
			atomic.AddInt64(&count, 1)
		}()
	}

	wg.Wait()
	// 原子读取最终值（确保读取操作也线程安全）
	fmt.Println("最终count值：", atomic.LoadInt64(&count)) // 稳定输出1000
}

关键点：

  • 原子操作仅支持特定类型（int32/int64/uint32/uint64等），且操作单一（增减、赋值、比较交换等）。
  • 读取原子变量时需用atomic.LoadXXX，避免因 CPU 缓存导致的 “不可见性” 问题。

二、GoFrame 框架实现

GoFrame（gf）框架对原生并发工具进行了封装，提供了更简洁的 API，同时保持了并发安全性。常用方案有：gsync.Mutex锁和 **gatomic原子操作工具 **。

1. gsync.Mutex：框架封装的互斥锁

gsync.Mutex兼容原生sync.Mutex，但提供了更丰富的功能（如超时锁、尝试锁等），适合复杂临界区。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
package main

import (
	"fmt"
	"sync"

	"github.com/gogf/gf/v2/os/gsync"
)

func main() {
	var count int
	var mu gsync.Mutex // 框架的互斥锁
	var wg sync.WaitGroup

	for i := 0; i < 1000; i++ {
		wg.Add(1)
		go func() {
			defer wg.Done()
			mu.Lock()   // 加锁
			count++
			mu.Unlock() // 解锁
		}()
	}

	wg.Wait()
	fmt.Println("最终count值：", count) // 稳定输出1000
}

优势：gsync.Mutex还支持TryLock()（尝试加锁，失败不阻塞）、LockWithTimeout()（超时自动放弃）等高级功能，避免死锁风险。

2. gatomic.Int64：框架的原子计数器

GoFrame 的gatomic包封装了原子操作，提供了更友好的面向对象 API，适合计数器场景。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
package main

import (
	"fmt"
	"sync"

	"github.com/gogf/gf/v2/os/gatomic"
)

func main() {
	var count gatomic.Int64 // 框架的原子计数器
	var wg sync.WaitGroup

	for i := 0; i < 1000; i++ {
		wg.Add(1)
		go func() {
			defer wg.Done()
			count.Add(1) // 原子加1
		}()
	}

	wg.Wait()
	fmt.Println("最终count值：", count.Val()) // 稳定输出1000
}

优势：

  • 无需手动调用atomic包的底层函数，API 更直观（Add/Val/Set等）。
  • 内部已处理类型安全和内存可见性问题，使用更简单。

三、方案选择建议

  1. 简单计数器场景：优先用sync/atomic（原生）或gatomic（GoFrame），性能最优。
  2. 复杂业务逻辑（如count+1前后有其他操作）：用sync.Mutex（原生）或gsync.Mutex（GoFrame），确保整个逻辑块的原子性。
  3. GoFrame 项目：推荐使用框架封装的gsync和gatomic，风格更统一，且扩展功能更丰富。

无论哪种方案，核心都是通过 “控制共享资源的访问顺序” 消除竞态条件，确保count+1操作在并发场景下的正确性。