Go的题目

文章目录

- 前置概念
- - 自旋
  - 同步原语是什么意思
  - sync.Mutex不是自旋锁
  - 互斥锁和读写锁的区别
- GMP
- - goroutine的调度策略
  - golang线程模型
  - 简述从全局队列里获取goroutine
  - 简述从本地队列里获取goroutine
  - Golang map是否并发/线程安全

前置概念

自旋

“自旋就是循环等待锁释放”

在Go语言（Golang）的上下文中，提到“自旋”时，通常指的是在多线程编程中的一种同步机制，具体来说是指线程或协程（在Go中称为goroutine）在试图获取某个锁时，如果发现该锁已被其他线程或goroutine占用，那么它不会立即进入阻塞状态（如调用操作系统服务挂起自己），而是进入一个循环（即“自旋”），在循环中不断尝试重新获取锁，直到成功获取或达到一定的自旋次数或时间阈值为止。

特点与应用场景：

避免上下文切换：自旋等待可以避免线程或goroutine因等待锁而被操作系统调度器挂起，从而减少了上下文切换的开销，这对于锁持有时间很短的情况可能更加高效，因为线程/goroutine能够更快地重新尝试获取锁，无需经历从用户态到内核态的转换以及后续的恢复过程。
有限的等待：自旋通常设定一个最大尝试次数或时间限制，防止无限期地占用处理器资源。一旦达到限制，自旋的线程/goroutine会停止循环并进入阻塞状态，等待操作系统唤醒。这样可以防止在锁长时间未释放的情况下持续消耗CPU资源。

Go语言中的自旋锁：虽然Go语言标准库并没有直接提供名为“自旋锁”的同步原语，但Go程序员可以通过编写类似自旋的行为来实现类似的逻辑。例如，在一个循环中不断尝试对某个互斥量（sync.Mutex）进行锁定，同时配合使用计数器或定时器来控制自旋的持续时间。

然而，Go语言推荐使用其内置的同步原语（如互斥锁、读写锁、通道等）来处理并发控制问题，这些原语通常已经考虑了适当的阻塞和唤醒机制，能够有效地利用操作系统的线程调度来管理并发。直接使用自旋可能会导致不必要的CPU使用率上升，尤其是在锁竞争激烈或锁持有时间较长的情况下。

总之，在Go语言编程中，“自旋”指的是线程或goroutine在等待锁时采用的一种循环检测而非立即阻塞的策略，目的是减少上下文切换的开销，但需谨慎使用，以免过度消耗CPU资源。在实践中，除非有特定的性能需求和精细的调优分析支持，否则一般建议依赖Go的标准同步工具包来管理并发。

同步原语是什么意思

同步原语是并发编程中用于协调多个线程（或在Go语言中为goroutines）之间同步行为的基本操作，这些操作通常由操作系统内核或高级语言的运行时系统提供。同步原语是构建更复杂同步机制的基础，确保在多线程或多进程环境中正确、安全地共享数据和资源。

以下是一些同步原语的关键特征和功能：

原子性：同步原语是不可分割的操作，它们在执行过程中不会被其他线程中断，确保了操作的完整性。这意味着一个线程在执行同步原语时，其他线程无法看到中间状态，只能看到操作前后的完整状态变化。
互斥：同步原语常常用于实现互斥访问，即确保同一时刻只有一个线程能够访问特定的临界区（critical section）或共享资源。这有助于防止数据竞争和竞态条件，维护数据一致性。
信号传递：同步原语还负责线程之间的信号传递，允许一个线程通知另一个线程某个条件已经满足，或者某个操作已经完成。这些信号通常是通过某种等待队列或条件变量来管理。
阻塞与唤醒：在需要等待某个条件满足时，同步原语能够使线程进入阻塞状态，暂时放弃执行权，直到满足特定条件后再被唤醒并重新获得执行机会。

常见的同步原语包括：

互斥锁（Mutexes）：如 sync.Mutex 或 sync.RWMutex，提供对共享资源的独占访问控制。一个线程在持有锁时，其他线程尝试获取锁会被阻塞，直到锁被释放。
信号量（Semaphores）：是一种更通用的同步机制，允许一定数量的线程同时访问共享资源。信号量维护一个计数器，线程可以“获取”（decrement）信号量，如果计数器非负，则获取成功；如果计数器为零，则线程被阻塞。线程也可以“释放”（increment）信号量，唤醒等待的线程。
条件变量（Condition Variables）：与互斥锁配合使用，允许线程在满足特定条件时等待和唤醒。线程可以调用 Wait() 方法释放锁并进入等待状态，当其他线程调用 Signal() 或 Broadcast() 方法时，等待的线程被唤醒并重新尝试获取锁。
屏障（Barriers）：一组线程在到达某个同步点（barrier point）时必须全部到达才能继续执行。屏障确保所有参与者都完成了指定阶段的工作，然后一起进入下一阶段。
读写锁（Read-Write Locks）：如 sync.RWMutex，允许多个读取者同时访问资源，但只允许一个写入者独占访问。这种原语特别适合读多写少的场景，可以提高并发读取的效率。
原子操作（Atomic Operations）：如 sync/atomic 包提供的原子整数操作，能够在不使用锁的情况下实现对数值类型的原子更新，常用于实现更精细的无锁数据结构。

同步原语是构建并发程序的基石，通过它们的组合使用，可以设计出复杂的同步逻辑，确保在多线程环境下程序的正确执行和数据的安全共享。

sync.Mutex不是自旋锁

sync.Mutex 在 Go 语言中实现的是传统的互斥锁（mutex），而非自旋锁。尽管在某些情况下，sync.Mutex 的实现可能包含自旋行为（如在尝试获取锁时短暂地循环检查锁的状态），但其核心机制并不是基于纯粹的自旋来等待锁的释放。

自旋锁通常是指一种线程同步机制，当线程试图获取已被其他线程持有的锁时，它不会立即进入阻塞状态（如调用操作系统服务挂起自己），而是进入一个循环（即“自旋”），在循环中不断尝试重新获取锁，直到成功获取或达到一定的自旋次数或时间阈值为止。

相比之下，sync.Mutex 的典型行为如下：

阻塞等待：当一个 goroutine 尝试获取已被其他 goroutine 持有的 sync.Mutex 时，它通常会立即进入阻塞状态，而不是持续消耗 CPU 周期去自旋。阻塞的 goroutine 会被 Go 的运行时调度器挂起，不再参与执行，直到锁被释放后它被唤醒。
操作系统交互：在阻塞和唤醒 goroutine 的过程中，Go 语言的运行时会与操作系统进行交互，如调用系统调用来实现线程的阻塞和唤醒。这是相对于自旋锁在用户态下循环检查锁状态而避免操作系统交互的一个显著区别。
效率考量：虽然在某些情况下（如预期锁持有时间极短），sync.Mutex 的实现可能包含短暂的自旋尝试以避免不必要的上下文切换开销，但这种行为通常是有限的并且是非主导策略。在大多数情况下，sync.Mutex 更倾向于快速地让出 CPU 并进入等待状态，以便其他 goroutines 或系统任务得以执行。

因此，尽管 sync.Mutex 的实现细节中可能包含一些自旋元素，但从其设计目的和典型行为来看，它更符合传统互斥锁的特点，即在无法立即获取锁时倾向于立即阻塞等待，而非持续自旋消耗 CPU。如果需要一个纯粹的自旋锁实现，通常需要自行编写或使用专门的第三方库提供的自旋锁类型。在 Go 语言标准库中，并没有直接提供名为“自旋锁”的同步原语。

互斥锁和读写锁的区别

在Go语言中，sync 包提供了两种常见的同步原语：sync.Mutex（互斥锁）和 sync.RWMutex（读写锁）。它们都用于保护共享数据的并发访问，确保在给定时刻只有一个goroutine修改或读取数据，但它们之间存在一些关键的区别：

sync.Mutex（互斥锁）
基本特性：

互斥：sync.Mutex 保证在任何时候最多只有一个 goroutine 拥有锁，即在同一时刻只有一个 goroutine 能够访问受保护的资源。
操作：提供了 Lock() 方法用于获取锁（如果锁不可用则阻塞），以及 Unlock() 方法用于释放锁。在持有锁的goroutine释放锁之前，其他尝试获取锁的goroutine将被阻塞。
用途：适用于任何需要独占访问共享资源的场景，无论是读操作还是写操作。当资源被修改或者需要整体一致性时，使用互斥锁是最简单且直接的选择。

sync.RWMutex（读写锁）
增强特性：

读写分离：sync.RWMutex 提供了更细粒度的控制，区分了读操作和写操作。它可以允许多个goroutine同时进行读操作，但写操作始终是互斥的。

读锁（RLock()）：多个goroutine可以同时获取读锁进行并发读取，互不阻塞。

写锁（Lock()）：写锁类似于互斥锁，同一时间只能有一个goroutine持有写锁。在有写锁存在时，任何新的读请求和写请求都会被阻塞，直到写锁被释放。
升级与降级：RWMutex 还支持锁的升级与降级，即已持有读锁的goroutine可以在必要时将其升级为写锁（需要先释放读锁再获取写锁），或者写锁持有者在完成写操作后将其降级为读锁（RUnlock() -> RLock()），这需要在代码中手动控制。
用途：

高读低写：适用于读操作远多于写操作的场景，读写锁能够在保持数据一致性的同时，提高读取密集型应用的并发性能。
避免写饥饿：由于读锁的共享特性，即使在大量连续读取的情况下，写操作也不会被完全阻塞，仍然有机会获得锁进行更新。
总结起来，sync.Mutex 和 sync.RWMutex 的主要区别在于：

互斥程度：Mutex 强制所有访问（读写）互斥，而 RWMutex 允许多个读取者并发访问。
适用场景：对于读多写少的场景，RWMutex 能提供更高的并发性和系统利用率；对于写操作频繁或读写比例接近的情况，Mutex 的简单互斥控制可能更为合适，因为它没有额外的锁状态管理开销。
选择使用哪种锁取决于具体的并发访问模式和性能需求。在实际编程中，应根据共享资源的访问特性来决定使用互斥锁还是读写锁，以平衡并发性能与数据一致性。

GMP

goroutine的调度策略

Go语言的goroutine调度策略是其并发模型的核心组成部分，旨在高效地利用硬件资源，处理大量的并发任务。以下是goroutine调度策略的主要方面：

GPM模型：Go语言运行时(runtime)层面实现了一套调度系统，即GPM模型。其中，G代表goroutine，P代表处理器(Processor)，用于执行goroutine的上下文环境，而M则代表操作系统线程。这种模型允许Go运行时动态地分配和管理goroutine的执行。
工作窃取：当P的本地队列中没有goroutine可供执行时，它会尝试从全局队列或其他P的本地队列中窃取goroutine来执行。这种策略有助于平衡负载，避免某些P的空闲而其他P过载的情况。
手动抢占：为了防止一个goroutine长时间占用P而导致其他goroutine饿死，Go的调度器会定期地进行抢占操作。从Go 1.14开始，引入了异步抢占，允许在任何安全点进行抢占，这进一步提高了调度的灵活性和效率。
栈管理：与操作系统的线程不同，goroutine的栈大小是不固定的。它们从很小的栈开始，然后根据需要增长或缩小。这种灵活的栈管理策略使得创建大量的goroutine成为可能，且不会浪费过多的内存资源。
调度器特性：Go运行时还实现了一些调度器的特性，以提高性能和资源利用率。例如，它使用了一种称为"M:N调度"的策略，其中M表示操作系统的线程，N表示goroutine。这意味着Go运行时会创建一组操作系统线程来执行goroutine，从而充分利用多核处理器的性能。

综上所述，Go语言的goroutine调度策略通过结合GPM模型、工作窃取、手动抢占、灵活的栈管理以及高效的调度器特性，实现了高效的并发执行和资源利用。这使得Go语言在处理大量并发任务时表现出色，成为构建高性能并发应用的理想选择。

参考：
https://www.jiguiquan.com/?p=3814
https://juejin.cn/post/7311893415151468584
https://cloud.tencent.com/developer/article/2370175
https://learnku.com/articles/84920

golang线程模型

Go语言的线程模型主要基于GMP（Goroutine-M-Processor）模型。这种模型在运行时层面进行了优化，以充分利用多核处理器资源，实现高效的并发执行。

在GMP模型中，Goroutine是Go语言中的轻量级线程，用于执行并发任务。它们由Go运行时系统进行调度和管理，而不是由操作系统直接管理。每个Goroutine都拥有自己的栈空间和执行上下文，可以在不同的M（OS线程）之间切换执行。

M代表操作系统线程，是实际执行代码的线程。Go运行时系统会根据系统的CPU核数创建相应数量的M，以充分利用多核资源。当Goroutine数量多于M的数量时，Go运行时系统会通过调度器将Goroutine分配到不同的M上执行，以实现并发执行的效果。

P（Processor）在GMP模型中扮演着处理器的角色，它包含了执行Goroutine所需的资源，如调度队列和本地缓存等。P的数量通常与系统的CPU核数相等，用于控制可同时并行执行的任务数量。每个P都会维护一个Goroutine队列，用于存放待执行的Goroutine。当M空闲时，它会从某个P的Goroutine队列中取出Goroutine来执行。

Go语言的线程模型通过这种GMP的结构，实现了高效的并发执行和内存管理。它避免了传统线程模型中的一些问题，如线程创建和销毁的开销、线程切换的成本以及内存泄漏等。同时，通过协程的轻量级和灵活的调度方式，Go语言能够更好地利用多核处理器资源，提高程序的执行效率。

需要注意的是，虽然Go语言内部使用了GMP模型来管理并发任务，但对于开发者来说，他们并不需要直接操作M或P。开发者只需要创建Goroutine并编写相应的并发逻辑，Go运行时系统会负责Goroutine的调度和执行。这使得开发者能够更专注于业务逻辑的实现，而无需过多关注底层的线程管理。

简述从全局队列里获取goroutine

GMP模型是Go语言运行时系统中用于调度goroutine的模型，其中G代表goroutine，M代表内核级线程，P代表逻辑处理器。在GMP模型中，全局队列（Global Queue）扮演着保存待执行goroutine的重要角色。

在GMP调度过程中，当M（即线程）尝试从本地队列（P的队列）获取goroutine执行时，如果本地队列为空，M会尝试从全局队列中获取goroutine。全局队列中存放着等待运行的goroutine，当新的goroutine被创建时，如果本地队列已满（通常容量为256），它们会被放入全局队列中等待执行。

此外，如果M在全局队列中也未能获取到goroutine，它还会尝试从其他P的本地队列中“偷取”一部分goroutine。这种机制有助于平衡不同P之间的负载，确保资源得到高效利用。

需要注意的是，全局队列和本地队列的存在以及M从队列中获取goroutine的过程都是GMP调度模型的一部分，它们共同协作以确保goroutine能够高效地在M上执行。同时，GMP模型还涉及其他复杂的调度策略和机制，如P的创建和销毁、M的阻塞和创建等，这些共同构成了Go语言强大且灵活的并发模型。

总之，在GMP模型中，从全局队列获取goroutine是调度过程中的一个环节，它与其他调度策略和机制共同协作，确保goroutine能够在多线程环境中得到高效且公平的调度执行。

简述从本地队列里获取goroutine

在GMP（Goroutine, Machine, Processor）模型中，goroutine的调度和执行是一个复杂但高效的过程。每个P（Processor）都维护一个本地队列，用于存放待执行的goroutine。这个本地队列在GMP模型中扮演着至关重要的角色，因为它允许goroutine在无需访问全局队列的情况下就能被快速调度和执行，从而提高了整体的并发性能。

当一个新的goroutine被创建时，它首先会被尝试放入其所在P的本地队列中。如果本地队列未满，goroutine就会直接被放入队列中等待执行。由于本地队列的访问通常比全局队列更快，因此这种方式能够减少线程间的竞争和同步开销，提高调度效率。

当M（Machine，即内核级线程）需要执行一个goroutine时，它会首先查看其关联的P的本地队列。如果本地队列中有可用的goroutine，M就会直接从队列中取出一个goroutine来执行。这个过程是高效的，因为M和P之间的关联是固定的，所以M可以快速地访问其关联的P的本地队列。

如果本地队列为空，M会尝试从全局队列中获取goroutine。全局队列是所有P共享的，存放着等待执行的goroutine。然而，由于全局队列的访问涉及到线程间的同步和竞争，因此其性能通常不如本地队列。因此，GMP模型通过优先使用本地队列来减少全局队列的使用，从而提高整体性能。

此外，GMP模型还采用了一种“工作窃取”（Work Stealing）的策略。当M在其关联的P的本地队列中找不到可用的goroutine时，它会尝试从其他P的本地队列中“偷取”一些goroutine来执行。这种策略有助于平衡不同P之间的负载，确保所有的goroutine都能得到及时执行。

综上所述，GMP模型通过本地队列和全局队列的结合使用，以及工作窃取策略的应用，实现了高效且公平的goroutine调度。在本地队列中获取goroutine是这一模型的核心部分，它确保了goroutine能够快速地被调度和执行，从而提高了Go程序的并发性能。