常用的锁

在并发编程中，锁是用于同步线程、避免数据竞争和确保线程安全的重要机制。

互斥锁（Mutex）

互斥锁是最基本的锁类型，确保同一时间只有一个线程可以访问共享资源。

• 线程获取锁后，其他尝试获取锁的线程会被阻塞，直到锁被释放。
• 通常用于保护临界区（Critical Section）。
• 实现简单，但可能导致线程阻塞和上下文切换开销。

用于需要确保独占访问共享资源的场景。

读写锁（Read-Write Lock）

允许多个线程同时读取共享资源，但写操作需独占访问。

• 读锁：多个线程可同时持有读锁（共享锁）。
• 写锁：写锁是独占的，写时不允许其他读或写操作。
• 提高并发性能，尤其在读多写少的场景。

是互斥锁的一种扩展，区分读写操作以提升性能。

用于读操作频繁、写操作较少的场景，如数据库缓存。

条件锁（Condition Lock）

结合条件变量，用于线程间的协作，线程在特定条件满足时才继续执行。

• 通常与互斥锁配合使用，线程等待条件满足时进入休眠，条件满足时被唤醒。
• 提高效率，避免忙等待。

条件锁依赖互斥锁，互斥锁保护共享条件变量。

用于生产者-消费者模型、线程同步等待。

信号量（Semaphore）

一种计数器机制，控制多个线程对有限资源的访问。

• 允许指定数量的线程同时访问资源（计数>1）。
• 当计数为1时，行为类似于互斥锁。

信号量是互斥锁的泛化，支持多线程并发访问。互斥锁限制为单一线程访问。

用于限制并发访问数量，如连接池管理。

分布式锁

在分布式系统中，用于协调多个进程或节点对共享资源的访问。

• 跨机器实现，通常基于外部存储（如Redis、ZooKeeper、Etcd）。
• 需考虑网络延迟、节点故障等复杂情况。

分布式锁是互斥锁的分布式扩展，适用于跨进程或跨机器场景。本地锁（如Mutex）仅限于单机多线程。

用于分布式系统中协调跨进程或跨节点的资源访问，如分布式任务调度。

悲观锁和乐观锁（加锁策略）

悲观锁（Pessimistic Lock）

悲观锁假设并发操作中冲突（数据竞争）发生的概率较高，因此在访问共享资源之前，总是先获取锁，确保独占访问。其他线程在锁被释放前会被阻塞。

适用于写操作频繁、冲突概率高、数据一致性要求严格的场景。
如互斥锁、读写锁、数据库锁（行锁、表锁）。

乐观锁（Optimistic Lock）

乐观锁假设并发操作中冲突发生的概率较低，允许线程先执行操作，在提交时检查数据是否被修改。
如果未被修改，则提交成功；否则，回滚并重试。乐观锁通常不使用传统锁机制，而是依赖版本控制或原子操作。

乐观锁是非阻塞的，线程直接操作共享资源，而无需等待锁。
通过版本号、时间戳或CAS（Compare-And-Swap）检查数据是否被修改。

适用于读多场景，高并发低冲突。
如缓存更新、计数器

阻塞锁和非阻塞锁（等待机制）

阻塞锁（Blocking Lock）

阻塞锁是指当线程尝试获取锁时，如果锁已被其他线程占用，当前线程会进入阻塞状态（挂起），等待锁释放。
阻塞状态通常由操作系统管理，线程被放入等待队列，暂停执行，直到被唤醒。

锁不可用时，线程被挂起，释放CPU资源。
但通常涉及线程的上下文切换（从用户态到内核态），开销较高。
线程唤醒和重新调度可能引入延迟。

适用于需要强一致性、长时间持有锁或高冲突场景。
互斥锁、读写锁、条件锁都属于阻塞锁。

非阻塞锁（Non-Blocking Lock）

非阻塞锁是指当线程尝试获取锁时，如果锁不可用，线程不会进入阻塞状态，而是立即返回（失败）或通过忙等待（busy-waiting）继续尝试。
非阻塞锁通常基于原子操作实现，尽量避免操作系统介入。

锁不可用时，线程要么立即返回，要么短暂自旋（循环尝试）。
基于原子操作（如CAS、Test-and-Set），通常在用户态完成。
自旋可能浪费CPU资源，但避免上下文切换。

适用于需要高吞吐量、短锁持有时间、冲突概率较低的场景。
自旋锁、乐观锁属于非阻塞锁。TryLock机制用于快速失败（尝试获取锁，失败则立即返回）。

可重入锁和非可重入锁（重入性）

基于锁是否允许同一线程多次获取的特性进行分类。
它们在实现线程安全和避免死锁方面有显著差异。

可重入锁（Reentrant Lock）

可重入锁允许同一线程多次获取同一把锁而不会导致死锁。每次获取锁时，锁内部会记录重入次数，线程必须释放相同次数的锁才能完全解锁。

同一线程可多次调用Lock()，每次增加锁的计数器。
释放时需调用Unlock()与Lock()次数相同，计数器减为0时锁被释放。

适用于复杂逻辑中，同一线程多次进入临界区（递归函数或嵌套调用）的场景。

非可重入锁（Non-Reentrant Lock）

非可重入锁不允许同一线程多次获取同一把锁。如果线程尝试重复加锁，会导致死锁或异常。

适用于简单互斥场景。

公平锁和非公平锁（分配策略）

根据锁的分配策略分类。
区别在于当多个线程（或goroutine）竞争锁时，锁是否按照线程请求的顺序（通常是先到先得）分配。

公平锁（Fair Lock）

公平锁确保线程按照请求锁的顺序获取锁，通常采用先到先得（FIFO，First-In-First-Out）策略。
当锁释放时，等待队列中最先请求的线程优先获得锁。

线程按请求顺序获取锁，避免线程饥饿（某些线程长期无法获取锁）。
维护了一个队列，用于记录线程的请求顺序。在锁被释放时，唤醒队列头部的线程。

适用于需要严格公平性、避免线程饥饿的场景。
需要维护队列，性能相对较低。

非公平锁（Non-Fair Lock）

非公平锁不保证线程按请求顺序获取锁。
当锁释放时，等待线程和新请求线程竞争锁，操作系统或运行时决定哪个线程获得锁，可能导致后请求的线程优先获取。

不保证FIFO，可能导致线程饥饿（某些线程长期无法获取锁）。

适用于追求高性能、允许一定程度不公平的场景。

锁会引发的问题

死锁（deadlock）

多个线程互相持有对方需要的锁，导致所有线程无法继续执行。

死锁产生的四个必要条件（梦回操作系统课）：

• 互斥条件：一个资源每次只能被一个进程使用。
• 请求与保持条件：一个进程因请求资源而阻塞时，对已获得的资源保持不放。
• 不剥夺条件：进程已获得的资源，在没使用完之前，不能强行剥夺。
• 循环等待条件：多个进程之间形成一种互相循环等待资源的关系。

发生场景：

• 多个锁的嵌套获取，且顺序不一致。
• 非可重入锁（如sync.Mutex）在同一线程重复加锁。

解决方法（破坏四个必要条件）：

• 统一线程的请求锁的顺序，以保证线程能获取到所需的全部资源而不阻塞，进而保证不发生死锁。
• 避免线程持有锁并等待锁。在请求锁时，如果锁被其他线程占用，不等待，而是将之前持有的锁释放，保证其他线程顺利执行。

活锁（Livelock）

线程不断尝试获取锁但无法成功，处于活跃但无进展的状态。
活锁其实是避免死锁的一种方式——避免线程持续尝试获取锁，而是通过等待或随机退避来避免。

举个例子：
在一个比较窄但允许两人同行的马路上，两个人相对而行，如果两个人相撞
死锁是：两个人僵持不动，谁都无法往前走
活锁是：两个人都很客气的让路给对方，但是两人同时移动到另一侧，又继续相撞，再移动回来又相撞，一直这样持续下去，那么就会发生活锁

活锁发生的概率是非常非常低的，两人的移动必须一直保持完全同步才可以，不然很快就可以解锁

发生场景：

• 非阻塞锁（如自旋锁）在高竞争下持续重试。
• 两个线程互相礼让锁（如CAS失败后退避）。

解决方法：

• 引入随机退避（如指数退避）。
• 限制重试次数，切换到阻塞锁。

线程饥饿（Starvation）

死锁或活锁描述的是多个线程的整体状态，线程饥饿描述的是单个线程的状态。
饥饿是某些线程长期无法获取锁，导致无法执行。

发生场景：

• 非公平锁（如sync.Mutex）优先新请求线程。
• 高优先级线程抢占锁。

解决方法：

• 使用公平锁。
• 调整线程优先级或调度策略。

优先级反转（Priority Inversion）

高优先级线程因等待低优先级线程释放共享资源（如锁）而被阻塞，而低优先级线程可能被其他中优先级线程抢占，导致高优先级线程的执行延迟。
这种现象违背了优先级调度原则，可能导致实时系统无法满足时间要求。

发生场景：

• 实时系统中，低优先级线程持有锁，高优先级线程被阻塞。

解决方法：

• 优先级继承（低优先级线程临时提升优先级，确保低优先级的线程优先于中优先级线程运行，尽快释放锁。）
• 优先级提升（为每个锁设置最高优先级，持有锁的线程提升到该优先级）

伪唤醒（Spurious Wakeup）

伪唤醒是指线程在等待条件变量（如条件锁）时，被操作系统或运行时无故唤醒，而条件并未满足。

伪唤醒是操作系统或并发库实现条件变量时的一种副作用，其原因主要与底层实现和优化相关。
操作系统可能设计为允许伪唤醒，在Signal()或Broadcast()时唤醒多个等待线程，而不是精确唤醒一个。以提高效率或简化同步原语的实现，防止复杂场景下的死锁或错误。
伪唤醒是条件变量实现的“不可避免副作用”，标准（如POSIX、C++）明确允许其存在。
设计上，条件变量不保证“仅当条件满足时唤醒”，因此在使用条件锁时需要额外的处理。

解决方法：

• 使用循环检查条件

由单次检查条件改为循环检查条件：

mu.Lock()
if !condition() {
    cond.Wait()
}
mu.Unlock()

mu.Lock()
for !condition() {
    cond.Wait()
}
mu.Unlock()

ABA问题

ABA问题是指在并发环境中，线程读取共享变量的值为A，准备通过CAS更新时，变量可能被其他线程修改为B后再改回A。由于CAS只检查值是否为A，线程误认为变量未被修改，执行更新操作，导致逻辑错误。

• 可能导致数据不一致（如无锁栈中重复使用已释放的内存）。
• 破坏程序逻辑，尤其在涉及指针或资源管理的场景。

任何基于CAS操作的并发控制机制，比如非阻塞锁（自旋锁、乐观锁）、无锁数据结构等，都会引发ABA问题。
涉及内存重用（如指针回收后重新分配相同地址）也会引发。

ABA问题的核心是CAS无法区分“值未变”和“值变回原值”。

解决方法：

• 版本号/时间戳：CAS检查值和版本，两次CAS，分别比较。
• 双字CAS（Compare-And-Swap-Double），同时比较两个值（如值和版本号）：单次CAS，需要硬件支持DCAS。
• 垃圾回收：垃圾回收可以避免指针立即重用，降低ABA问题风险。
• Tagged Pointers：在指针中嵌入版本信息，CAS操作检查整个指针（值+版本），避免ABA问题，复杂实现。
• 避免指针重用：使用新分配内存或对象池，避免值恢复原状。
• 阻塞锁：如sync.Mutex，完全避免ABA。