摘要：线程安全：就是多个线程在访问共享资源时，能够正确地执⾏，不会相互⼲扰或破坏彼此的执⾏结果，也不会出现数据不一致的问题。⼀般⽽⾔，多个线程并发同⼀段只有局部变量的代码时，不会出现不同的结果。但是对全局变量或者静态变量进⾏操作，并且没有锁保护的情况下，容易出现该问

多线程重⼊函数。

信号导致⼀个执⾏流重复进⼊函数。

可重⼊与线程安全联系

🍡 函数是可重⼊的，那就是线程安全的 (其实知道这⼀句话就够了) ：

🍡 函数是不可重⼊的，那就不能由多个线程使⽤，有可能引发线程安全问题

🍡 如果⼀个函数中有全局变量，那么这个函数既不是线程安全也不是可重⼊的。

🦋 可重⼊与线程安全区别

🍡 可重⼊函数是线程安全函数的⼀种

🍡 线程安全不⼀定是可重⼊的，⽽可重⼊函数则⼀定是线程安全的。

🍡 如果将对临界资源的访问加上锁，则这个函数是线程安全的，但如果这个重⼊函数若锁还未释放则会产⽣死锁，因此是不可重⼊的。

·📌 注意：

如果不考虑 信号导致⼀个执⾏流重复进⼊函数 这种重⼊情况，线程安全和重⼊在安全⻆度不做区分

但是线程安全侧重说明线程访问公共资源的安全情况，表现的是 并发线程的特点

可重⼊描述的是⼀个函数是否能被重复进⼊，表⽰的是 函数的特点

二：🔥 常⻅锁概念

🦋 2-1 死锁

死锁是指在⼀组进程中的各个进程均占有不会释放的资源，但因互相申请被其他进程所站⽤不会释放的资源⽽处于的⼀种永久等待状态。

为了⽅便表述，假设现在线程A，线程B必须同时持有锁1和锁2，才能进⾏后续资源的访问

申请⼀把锁是原⼦的，但是申请两把锁就不⼀定了

造成的结果是

2-3 避免死锁

破坏死锁的四个必要条件

破坏循环等待条件问题：资源⼀次性分配， 使⽤超时机制、加锁顺序⼀致

避免锁未释放的场景

🦋 2-4 避免死锁算法

• 死锁检测算法(了解)

• 银⾏家算法（了解）

三：🔥 STL,智能指针和线程安全

🦋 3-1 STL中的容器是否是线程安全的?

不是.

原因是, STL 的设计初衷是将性能挖掘到极致, ⽽⼀旦涉及到加锁保证线程安全, 会对性能造成巨⼤的影响.

⽽且对于不同的容器, 加锁⽅式的不同, 性能可能也不同(例如hash表的锁表和锁桶).

因此 STL 默认不是线程安全. 如果需要在多线程环境下使⽤, 往往需要调⽤者⾃⾏保证线程安全.

🦋 3-2 智能指针是否是线程安全的?

对于 unique_ptr, 由于只是在当前代码块范围内⽣效, 因此不涉及线程安全问题.

对于 shared_ptr, 多个对象需要共⽤⼀个引⽤计数变量, 所以会存在线程安全问题. 但是标准库实现的时候考虑到了这个问题, 基于原⼦操作(CAS)的⽅式保证 shared_ptr 能够⾼效, 原⼦的操作引⽤计数.

四：🔥 其他常⻅的各种锁

悲观锁：在每次取数据时，总是担⼼数据会被其他线程修改，所以会在取数据前先加锁（读锁，写锁，⾏锁等），当其他线程想要访问数据时，被阻塞挂起。

乐观锁：每次取数据时候，总是乐观的认为数据不会被其他线程修改，因此不上锁。但是在更新数据前，会判断其他数据在更新前有没有对数据进⾏修改。主要采⽤两种⽅式：版本号机制和CAS操作。

CAS操作：当需要更新数据时，判断当前内存

五：🔥 读者写者问题与读写锁

🦋 读者写者问题如何理解

下面是一段伪代码， 帮助我们理解读者写者的逻辑
公共部分

读写锁

在编写多线程的时候， 有一种情况是十分常见的。 那就是， 有些公共数据修改的机会比较少。 相比较改写， 它们读的机会反而高的多。 通常而言， 在读的过程中， 往往伴随着查找的操作， 中间耗时很长。 给这种代码段加锁， 会极大地降低我们程序的效率。 那么有没有一种方法， 可以专门处理这种多读少写的情况呢？有， 那就是读写锁。

初始化

销毁

加锁和解锁

读写锁案例：

读者优先（Reader-Preference）

在这种策略中， 系统会尽可能多地允许多个读者同时访问资源（比如共享文件或数据） ， 而不会优先考虑写者。 这意味着当有读者正在读取时， 新到达的读者会立即被允许进入读取区， 而写者则会被阻塞， 直到所有读者都离开读取区。 读者优先策略可能会导致写者饥饿（即写者长时间无法获得写入权限） ， 特别是当读者频繁到达时。

🦋 写者优先（Writer-Preference）

在这种策略中， 系统会优先考虑写者。 当写者请求写入权限时， 系统会尽快地让写者进入写入区， 即使此时有读者正在读取。 这通常意味着一旦有写者到达， 所有后续的读者都会被阻塞， 直到写者完成写入并离开写入区。 写者优先策略可以减少写者等待的时间， 但可能会导致读者饥饿（即读者长时间无法获得读取权限） ， 特别是当写者频繁到达时。

在这种策略中， 系统会尽可能多地允许多个读者同时访问资源（比如共享文件或数据） ， 而不会优先考虑写者。 这意味着当有读者正在读取时， 新到达的读者会立即被允许进入读取区， 而写者则会被阻塞， 直到所有读者都离开读取区。 读者优先策略可能会导致写者饥饿（即写者长时间无法获得写入权限） ， 特别是当读者频繁到达时。

🦋 写者优先（Writer-Preference）

在这种策略中， 系统会优先考虑写者。 当写者请求写入权限时， 系统会尽快地让写者进入写入区， 即使此时有读者正在读取。 这通常意味着一旦有写者到达， 所有后续的读者都会被阻塞， 直到写者完成写入并离开写入区。 写者优先策略可以减少写者等待的时间， 但可能会导致读者饥饿（即读者长时间无法获得读取权限） ， 特别是当写者频繁到达时。

六：🔥 自旋锁

🦋 概述

自旋锁是一种多线程同步机制， 用于保护共享资源免受并发访问的影响。 在多个线程尝试获取锁时， 它们会持续自旋（即在一个循环中不断检查锁是否可用） 而不是立即进入休眠状态等待锁的释放。 这种机制减少了线程切换的开销， 适用于短时间内锁的竞争情况。 但是不合理的使用， 可能会造成 CPU 的浪费。

🦋 原理

自旋锁通常使用一个共享的标志位（如一个布尔值） 来表示锁的状态。 当标志位为true 时， 表示锁已被某个线程占用； 当标志位为 false 时， 表示锁可用。 当一个线程尝试获取自旋锁时， 它会不断检查标志位：

如果标志位为 false， 表示锁可用， 线程将设置标志位为 true， 表示自己占用了锁， 并进入临界区。

如果标志位为 true（即锁已被其他线程占用） ， 线程会在一个循环中不断自旋等待， 直到锁被释放。

🦋 优点与缺点

🌶️ 优点

低延迟： 自旋锁适用于短时间内的锁竞争情况， 因为它不会让线程进入休眠状态， 从而避免了线程切换的开销， 提高了锁操作的效率。

减少系统调度开销： 等待锁的线程不会被阻塞， 不需要上下文切换， 从而减少了系统调度的开销。

🌶️ 缺点

CPU 资源浪费： 如果锁的持有时间较长， 等待获取锁的线程会一直循环等待， 导致 CPU 资源的浪费。

可能引起活锁： 当多个线程同时自旋等待同一个锁时， 如果没有适当的退避策略， 可能会导致所有线程都在不断检查锁状态而无法进入临界区， 形成活锁。

🦋 使用场景

短暂等待的情况： 适用于锁被占用时间很短的场景， 如多线程对共享数据进行简单的读写操作。

多线程锁使用： 通常用于系统底层， 同步多个 CPU 对共享资源的访问。

🦋 纯软件自旋锁类似的原理实现

自旋锁的实现通常使用原子操作来保证操作的原子性， 常用的软件实现方式是通过 CAS（Compare-And-Swap） 指令实现。 以下是一个简单的自旋锁实现示例（伪代码） ：

功能描述

atomic_flag_test_and_set 函数检查 atomic_flag 的当前状态。 如果atomic_flag 之前没有被设置过（即其值为 false 或“未设置”状态） ， 则函数会将其设置为 true（或“设置”状态） ， 并返回先前的值（在这种情况下为 false） 。 如果atomic_flag 之前已经被设置过（即其值为 true） ， 则函数不会改变其状态， 但会返回 true。

原子性

这个操作是原子的， 意味着在多线程环境中， 它保证了对 atomic_flag 的读取和修改是不可分割的。 当一个线程调用此函数时， 其他线程无法看到这个操作的任何中间状态， 这确保了操作的线程安全性。

Linux 提供的自旋锁系统调用

注意事项

在使用自旋锁时， 需要确保锁被释放的时间尽可能短， 以避免 CPU 资源的浪费。

在多 CPU 环境下， 自旋锁可能不如其他锁机制高效， 因为它可能导致线程在不同的 CPU 上自旋等待。

🦋 结论

自旋锁是一种适用于短时间内锁竞争情况的同步机制， 它通过减少线程切换的开销来提高锁操作的效率。 然而， 它也存在 CPU 资源浪费和可能引起活锁等缺点。 在使用自旋锁时， 需要根据具体的应用场景进行选择， 并确保锁被释放的时间尽可能短。

¥61.44京东购买

来源：阿晶科技时代