# golang 设计模式

Tags: Golang

Published: 2024年6月19日

概要: 本文介绍了Go语言中的设计模式，包括创建型模式、结构型模式和行为型模式，并提供了各种模式的示例代码和解析。




# **1 设计模式概述**

设计模式是啥呢？简单来说，就是将软件开发中需要重复性解决的编码场景，按最佳实践的方式抽象成一个模型，模型描述的解决方法就是设计模式。使用设计模式，可以使代码更易于理解，保证代码的重用性和可靠性。


![Untitled.png](https://cdn.jsdelivr.net/gh/Gypsophila1006/img/img/b946125f9605ba1b606b29740d919852.Untitled.webp)

# **2 创建型模式**

创建型模式（Creational Patterns），它提供了一种**在创建对象的同时隐藏创建逻辑**的方式，而不是使用 new 运算符直接实例化对象。

这种类型的设计模式里，单例模式和工厂模式（具体包括简单工厂模式、抽象工厂模式和工厂方法模式三种）在Go项目开发中比较常用。

## **2.1 单例模式**

单例模式的目的是为了保证一个类仅有一个实例，并提供一个访问它的全局访问点.

> 单例模式的两种表现形式。
> 
- 饿汉式：类加载时，就进行实例化。
- 懒汉式，第一次引用类时才进行实例化。

### **2.1.1 饿汉式**

> 单例对象是在包加载时立即被创建，所以这个方式叫作饿汉式
> 

`singleton` 包在被导入时会自动初始化 `instance` 实例，使用时通过调用 `singleton.GetSingleton()` 函数即可获得 `singleton` 这个结构体的单例对象。

```
package singleton

type singleton struct{}

var instance = &singleton{}

func GetSingleton() *singleton {
    return instance
}

```

### **2.1.2 懒汉式**

> 懒汉式模式下实例只有在第一次被使用时才被创建。
> 

```
package singleton

type singleton struct{}

var instance *singleton

func GetSingleton() *singleton {
    if instance == nil {
        instance = &singleton{}
    }
    return instance
}

```

### **2.1.3 并发安全**

> 懒汉式单例模式并发安全问题，比如在创建实例时，如果多个线程同时进行，则会出现并发问题。
> 

为了解决并发往问题，可以使用以下三种方法：

- 使用锁
- 使用sync/atomic包，原子化加载并设置一个标志，表明是否已初始化实例
- 使用sync.Once
    
    ```
    package singleton
    
    import "sync"
    
    type singleton struct{}
    
    var instance *singleton
    
    var once sync.Once
    
    func GetSingleton() *singleton {
        once.Do(func() {
            instance = &singleton{}
        })
        return instance
    }
    
    ```
    

`Once` 是一个结构体，在执行 `Do` 方法的内部通过 `atomic` 操作和加锁机制来保证并发安全，且 `once.Do` 能够保证多个 `goroutine` 同时执行时 `&singleton{}` 只被创建一次。

## **2.2 工厂模式**

工厂模式是创建型模式之一。由于创建类的代码和使用类的代码分离，符合单一职责和开闭原则，代码扩展性高.

> 按实际业务场景划分，工厂模式有 3 种不同的实现方式，俗称工厂三兄弟。
> 
- 简单工厂模式
- 工厂方法模式
- 抽象工厂模式

### **2.2.1 简单工厂模式**

> 简单工厂模式（Simple Factory Pattern）又称为静态工厂方法（Static Factory Method）模式。在简单工厂模式中，可以根据参数的不同返回不同类的实例。简单工厂模式专门定义一个类来负责创建其他类的实例，被创建的实例通常都具有共同的父类。
> 

> 优点
> 
- 创建类的代码和使用类的代码分离，符合单一职责和开闭原则，代码扩展性高。
- 客户端无需知道所创建具体产品的类名，只需知道参数即可。
- 也可以引入配置文件，在不修改客户端代码的情况下更换和添加新的具体产品类。

> 缺点
> 
- 简单工厂模式的工厂类单一，职责过重，一旦异常，整个系统将受影响。且违背开闭原则。
- 使用简单工厂模式会增加系统中类的个数（引入新的工厂类），增加系统的复杂度和理解难度。
- 系统扩展困难，一旦增加新产品不得不修改工厂逻辑，在产品类型较多时，可能造成逻辑过于复杂。

### **2.2.2 工厂方法模式**

> 工厂方法模式（Factory method pattern）是一种实现了工厂概念的面向对象设计模式。工厂方法模式定义一个用于创建对象的接口，但让实现这个接口的子类来决定实例化哪个类。工厂方法让类的实例化延迟到子类中进行。
> 

从工厂方法模式来看，工厂类不再单一，我们解耦了对产品的操作，每种操作都作为一种工厂类，做到了工厂隔离，后续如果需要新的产品，则只需要根据抽象的类来定义产品即可，再设计新的工厂生产产品，不会改动之前的任何代码，符合开闭原则思想。

> 优点
> 
- 不需要记住具体类名，甚至连具体参数都不用记忆。
- 系统的可扩展性也就变得非常好，无需修改接口和原类。
- 符合开闭原则。

> 缺点
> 
- 增加系统中类的个数，复杂度和理解度增加。
- 增加了系统的抽象性和理解难度。

### **2.2.3 抽象工厂模式**

> 抽象工厂模式（Abstract factory pattern）引出了产品族和产品等级结构概念，其目的是为了更加高效的生产同一个产品组产品。
> 

**产品等级结构：** 产品的等级结构就是产品的继承结构，如一个模型工厂，可以画出圆形，长方形和正方形的模型。这里抽象的模型工厂和具体的模型构成了产品等级结构。
**产品族：** 在抽象工厂模式中，产品族指的是同一个工厂生产的，位于不同产品等级结构的一组产品。如模具厂生产的红色圆形模具，圆形模型属于模型产品等级结构中，红色属于颜料产品等级结构中。


![Untitled 1.png](https://cdn.jsdelivr.net/gh/Gypsophila1006/img/img/af4660a5793972816783aa49aa3dfb80.Untitled%201.webp)
> 优点
> 
- 拥有工厂方法模式的优点。
- 当一个产品族中的多个对象被设计成一起工作时，它能够保证客户端始终只使用同一个产品族中的对象。
- 增加新的产品族很方便，无须修改已有系统，符合开闭原则。

> 缺点
> 
- 增加新的产品等级结构麻烦，需要对原有系统进行较大的修改，甚至需要修改抽象层代码，这显然会带来较大的不便，违背了开闭原则。

# **3 结构型模式**

特点是**关注类和对象的组合**。

## **3.1 策略模式**

策略模式（Strategy Pattern）定义一组算法，将每个算法都封装起来，并且使它们之间可以互换。

在什么时候，我们需要用到策略模式呢？

在项目开发中，我们经常要根据不同的场景，采取不同的措施，也就是不同的**策略**。比如，假设我们需要对a、b 这两个整数进行计算，根据条件的不同，需要执行不同的计算方式。我们可以把所有的操作都封装在同一个函数中，然后通过 `if ... else ...` 的形式来调用不同的计算方式，这种方式称之为**硬编码**。

在实际应用中，随着功能和体验的不断增长，我们需要经常添加/修改策略，这样就需要不断修改已有代码，不仅会让这个函数越来越难维护，还可能因为修改带来一些bug。所以为了解耦，需要使用策略模式，定义一些独立的类来封装不同的算法，每一个类封装一个具体的算法（即策略）。

```
package strategy

// 策略模式

// 定义一个策略类
type IStrategy interface {
  do(int, int) int
}

// 策略实现：加
type add struct{}

func (*add) do(a, b int) int {
  return a + b
}

// 策略实现：减
type reduce struct{}

func (*reduce) do(a, b int) int {
  return a - b
}

// 具体策略的执行者
type Operator struct {
  strategy IStrategy
}

// 设置策略
func (operator *Operator) setStrategy(strategy IStrategy) {
  operator.strategy = strategy
}

// 调用策略中的方法
func (operator *Operator) calculate(a, b int) int {
  return operator.strategy.do(a, b)
}
```

在上述代码中，我们定义了策略接口 IStrategy，还定义了 add 和 reduce 两种策略。最后定义了一个策略执行者，可以设置不同的策略，并执行，例如：

```
func TestStrategy(t *testing.T) {
  operator := Operator{}

  operator.setStrategy(&add{})
  result := operator.calculate(1, 2)
  fmt.Println("add:", result)

  operator.setStrategy(&reduce{})
  result = operator.calculate(2, 1)
  fmt.Println("reduce:", result)
}
```

## **3.2 模板模式**

模板模式 (Template Pattern)定义一个操作中算法的骨架，而将一些步骤延迟到子类中。这种方法让子类在不改变一个算法结构的情况下，就能重新定义该算法的某些特定步骤。

简单来说，模板模式就是将一个类中能够公共使用的方法放置在抽象类中实现，将不能公共使用的方法作为抽象方法，强制子类去实现，这样就做到了将一个类作为一个模板，让开发者去填充需要填充的地方。

```
package template

import "fmt"

type Cooker interface {
  fire()
  cooke()
  outfire()
}

// 类似于一个抽象类
type CookMenu struct {
}

func (CookMenu) fire() {
  fmt.Println("开火")
}

// 做菜，交给具体的子类实现
func (CookMenu) cooke() {
}

func (CookMenu) outfire() {
  fmt.Println("关火")
}

// 封装具体步骤
func doCook(cook Cooker) {
  cook.fire()
  cook.cooke()
  cook.outfire()
}

type XiHongShi struct {
  CookMenu
}

func (*XiHongShi) cooke() {
  fmt.Println("做西红柿")
}

type ChaoJiDan struct {
  CookMenu
}

func (ChaoJiDan) cooke() {
  fmt.Println("做炒鸡蛋")
}
```

```
func TestTemplate(t *testing.T) {
  // 做西红柿
  xihongshi := &XiHongShi{}
  doCook(xihongshi)

  fmt.Println("\n=====> 做另外一道菜")
  // 做炒鸡蛋
  chaojidan := &ChaoJiDan{}
  doCook(chaojidan)

}
```

# **4 行为型模式**

特点是关注**对象之间的通信**。

## **4.1 代理模式**

代理模式 (Proxy Pattern)，可以为另一个对象提供一个替身或者占位符，以控制对这个对象的访问。

```
package proxy

import "fmt"

type Seller interface {
  sell(name string)
}

// 火车站
type Station struct {
  stock int //库存
}

func (station *Station) sell(name string) {
  if station.stock > 0 {
    station.stock--
    fmt.Printf("代理点中：%s买了一张票,剩余：%d \n", name, station.stock)
  } else {
    fmt.Println("票已售空")
  }

}

// 火车代理点
type StationProxy struct {
  station *Station // 持有一个火车站对象
}

func (proxy *StationProxy) sell(name string) {
  if proxy.station.stock > 0 {
    proxy.station.stock--
    fmt.Printf("代理点中：%s买了一张票,剩余：%d \n", name, proxy.station.stock)
  } else {
    fmt.Println("票已售空")
  }
}
```

上述代码中，StationProxy代理了Station，代理类中持有被代理类对象，并且和被代理类对象实现了同一接口。

## **4.2 选项模式**

在Python语言中，创建一个对象时，可以给参数设置默认值，这样在不传入任何参数时，可以返回携带默认值的对象，并在需要时修改对象的属性。这种特性可以大大简化开发者创建一个对象的成本，尤其是在对象拥有众多属性时。

而在Go语言中，因为不支持给参数设置默认值，为了既能够创建带默认值的实例，又能够创建自定义参数的实例，不少开发者会通过以下两种方法来实现：

第一种方法，我们要分别开发两个用来创建实例的函数，一个可以创建带默认值的实例，一个可以定制化创建实例。

使用这种方式，创建同一个Connection实例，却要实现两个不同的函数，实现方式很不优雅。

另外一种方法相对优雅些。我们需要创建一个带默认值的选项，并用该选项创建实例：

```
package options

import (
  "time"
)

const (
  defaultTimeout = 10
  defaultCaching = false
)

type Connection struct {
  addr    string
  cache   bool
  timeout time.Duration
}

type ConnectionOptions struct {
  Caching bool
  Timeout time.Duration
}

func NewDefaultOptions() *ConnectionOptions {
  return &ConnectionOptions{
    Caching: defaultCaching,
    Timeout: defaultTimeout,
  }
}

// NewConnect creates a connection with options.
func NewConnect(addr string, opts *ConnectionOptions) (*Connection, error) {
  return &Connection{
    addr:    addr,
    cache:   opts.Caching,
    timeout: opts.Timeout,
  }, nil
}
```

使用这种方式，虽然只需要实现一个函数来创建实例，但是也有缺点：为了创建Connection实例，每次我们都要创建ConnectionOptions，操作起来比较麻烦。

那么有没有更优雅的解决方法呢？答案当然是有的，就是使用选项模式来创建实例。以下代码通过选项模式实现上述功能：

```
package options

import (
  "time"
)

type Connection struct {
  addr    string
  cache   bool
  timeout time.Duration
}

const (
  defaultTimeout = 10
  defaultCaching = false
)

type options struct {
  timeout time.Duration
  caching bool
}

// Option overrides behavior of Connect.
type Option interface {
  apply(*options)
}

type optionFunc func(*options)

func (f optionFunc) apply(o *options) {
  f(o)
}

func WithTimeout(t time.Duration) Option {
  return optionFunc(func(o *options) {
    o.timeout = t
  })
}

func WithCaching(cache bool) Option {
  return optionFunc(func(o *options) {
    o.caching = cache
  })
}

// Connect creates a connection.
func NewConnect(addr string, opts ...Option) (*Connection, error) {
  options := options{
    timeout: defaultTimeout,
    caching: defaultCaching,
  }

  for _, o := range opts {
    o.apply(&options)
  }

  return &Connection{
    addr:    addr,
    cache:   options.caching,
    timeout: options.timeout,
  }, nil
}
```

在上面的代码中，首先我们定义了`options`结构体，它携带了timeout、caching两个属性。接下来，我们通过`NewConnect`创建了一个连接，`NewConnect`函数中先创建了一个带有默认值的`options`结构体变量，并通过调用

for _, o := range opts {

o.apply(&options)

}

来修改所创建的`options`结构体变量。

需要修改的属性，是在`NewConnect`时，通过Option类型的选项参数传递进来的。可以通过`WithXXX`函数来创建Option类型的选项参数：WithTimeout、WithCaching。

Option类型的选项参数需要实现`apply(*options)`函数，结合WithTimeout、WithCaching函数的返回值和optionFunc的apply方法实现，可以知道`o.apply(&options)`其实就是把WithTimeout、WithCaching传入的参数赋值给options结构体变量，以此动态地设置options结构体变量的属性。

这里还有一个好处：我们可以在apply函数中自定义赋值逻辑，例如`o.timeout = 100 * t`。通过这种方式，我们会有更大的灵活性来设置结构体的属性。

选项模式有很多优点，例如：支持传递多个参数，并且在参数发生变化时保持兼容性；支持任意顺序传递参数；支持默认值；方便扩展；通过WithXXX的函数命名，可以使参数意义更加明确，等等。

不过，为了实现选项模式，我们增加了很多代码，所以在开发中，要根据实际场景选择是否使用选项模式。选项模式通常适用于以下场景：

- 结构体参数很多，创建结构体时，我们期望创建一个携带默认值的结构体变量，并选择性修改其中一些参数的值。
- 结构体参数经常变动，变动时我们又不想修改创建实例的函数。例如：结构体新增一个retry参数，但是又不想在NewConnect入参列表中添加`retry int`这样的参数声明。

如果结构体参数比较少，可以慎重考虑要不要采用选项模式。

# **5 总结**


![Untitled 2.png](https://cdn.jsdelivr.net/gh/Gypsophila1006/img/img/b946125f9605ba1b606b29740d919852.Untitled.webp)

golang 设计模式

分布式事务Seata

字节面试总结

# 使用 Redis 快速实现分布式锁

Tags: Redis, 分布式

Published: 2024年6月23日

# 分布式锁的需求


![Untitled.png](https://cdn.jsdelivr.net/gh/Gypsophila1006/img/img/082816759ad050cd9afc3d4aec3d7796.Untitled.webp)

一般来说，生产环境可用的分布式锁需要满足以下几点：

- **互斥性**，互斥是锁的基本特征，同一时刻只能有一个线程持有锁，执行临界操作；
- **超时释放**，超时释放是锁的另一个必备特性，可以对比 MySQL InnoDB 引擎中的 innodb_lock_wait_timeout 配置，通过超时释放，防止不必要的线程等待和资源浪费；
- **可重入性**，在分布式环境下，同一个节点上的同一个线程如果获取了锁之后，再次请求还是可以成功；
- **高性能和高可用**，加锁和解锁的开销要尽可能的小，同时也需要保证高可用，防止分布式锁失效；
- **支持阻塞和非阻塞性**，这个一般是在业务代码中实现，比如在获取锁时通过 while(true) 或者轮询来实现阻塞操作。

# Redis实现分布式锁的方法

## **使用 setnx 实现分布式锁**

Redis 支持 setnx 指令，只在 key 不存在的情况下，将 key 的值设置为 value，若 key 已经存在，则 setnx 命令不做任何动作。如果 setnx 返回 1，则说明该进程获得锁；如果 setnx 返回 0，则说明其他进程已经获得了锁，进程不能进入临界区；如果需要阻塞当前进程，可以在一个循环中不断尝试 setnx 操作。

对比一下上面说的分布式锁特性，使用这种方式实现分布式锁的问题很明显：不支持超时释放锁，如果进程在加锁后宕机，则会导致锁无法删除，其他进程无法获得锁。

## **使用 setnx 和 expire 实现**

在分布式锁的实现中，依赖业务线程进行锁的释放，如果进程宕机，那么就会出现死锁。Redis 在设置一个 key 时，支持设置过期时间，利用这一点，可以在缓存中实现锁的超时释放，解决死锁问题。

在使用 setnx 获取锁之后，通过 expire 给锁加一个过期时间，利用 Redis 的缓存失效策略，进行锁的超时清除。

通过设置过期时间，避免了占锁到释放锁的过程发生异常而导致锁无法释放的问题，但是在 Redis 中，**setnx 和 expire 这两条命令不具备原子性**。如果一个线程在执行完 setnx 之后突然崩溃，导致锁没有设置过期时间，那么这个锁就会一直存在，无法被其他线程获取。

## **使用 set 扩展命令实现**

为了解决这个问题，在 Redis 2.8 版本中，扩展了 set 命令，支持 set 和 expire 指令组合的原子操作，解决了加锁过程中失败的问题。

```abap
redis> SET key value expireTime nx
```

nx 表示仅在键不存在时设置，这样可以在同一时间内完成设置值和设置过期时间这两个操作，防止设置过期时间异常导致的死锁。那么这种方式还存在问题吗？

使用 setex 方式看起来解决了锁超时的问题，但在实际业务中，如果对超时时间设置不合理，存在这样一种可能：在加锁和释放锁之间的业务逻辑执行的太长，以至于超出了锁的超时限制，缓存将对应 key 删除，其他线程可以获取锁，出现对加锁资源的并发操作。

**如何避免这个问题呢？**

- 首先，基于 Redis 的分布式锁一般是用于耗时比较短的瞬时性任务，业务上超时的可能性较小
- 其次，在获取锁时，可以设置 value 为一个随机数，在释放锁时进行读取和对比，确保释放的是当前线程持有的锁，一般是通过 Redis 结合 Lua 脚本的方案实现；
- 最后，需要添加完备的日志，记录上下游数据链路，当出现超时，则需要检查对应的问题数据，并且进行人工修复。

# **分布式锁的高可用**

上面分布式锁的实现方案中，都是针对单节点 Redis 而言的，在生产环境中，为了保证高可用，避免单点故障，通常会使用 Redis 集群。

## **集群下分布式锁存在哪些问题**

集群环境下，Redis 通过主从复制来实现数据同步，Redis 的主从复制（Replication）是异步的，所以单节点下可用的方案在集群的环境中可能会出现问题，在故障转移（Failover） 过程中丧失锁的安全性。

由于 Redis 集群数据同步是异步的，假设 Master 节点获取到锁后在未完成数据同步的情况下，发生节点崩溃，此时在其他节点依然可以获取到锁，出现多个客户端同时获取到锁的情况。

我们模拟下这个场景，按照下面的顺序执行：

- 客户端 A 从 Master 节点获取锁；
- Master 节点宕机，主从复制过程中，对应锁的 key 还没有同步到 Slave 节点上；
- Slave 升级为 Master 节点，于是集群丢失了锁数据；
- 其他客户端请求新的 Master 节点，获取到了对应同一个资源的锁；
- 出现多个客户端同时持有同一个资源的锁，不满足锁的互斥性。

关于在集群中如何实现分布式锁，可以使用Redlock算法

## **Redlock 算法**

**Redlock 算法**是在单 Redis 节点基础上引入的**高可用模式**，Redlock 基于 N 个完全独立的 Redis 节点，一般是**大于 3 的奇数个**（通常情况下 N 可以设置为 5），可以基本保证集群内各个节点不会同时宕机。

假设当前集群有 5 个节点，运行 Redlock 算法的客户端依次执行下面各个步骤，来完成获取锁的操作：

- 客户端记录当前系统时间，以毫秒为单位；
- 依次尝试从 5 个 Redis 实例中，使用相同的 key 获取锁，当向 Redis 请求获取锁时，客户端应该设置一个网络连接和响应超时时间，超时时间应该小于锁的失效时间，避免因为网络故障出现的问题；
- 客户端使用当前时间减去开始获取锁时间就得到了获取锁使用的时间，当且仅当从半数以上的 Redis 节点获取到锁，并且当使用的时间小于锁失效时间时，锁才算获取成功；
- 如果获取到了锁，key 的真正有效时间等于有效时间减去获取锁所使用的时间，减少超时的几率；
- 如果获取锁失败，客户端应该在所有的 Redis 实例上进行解锁，即使是上一步操作请求失败的节点，防止因为服务端响应消息丢失，但是实际数据添加成功导致的不一致。

> 分布式系统设计是实现复杂性和收益的平衡，考虑到集群环境下的一致性问题，也要避免过度设计。在实际业务中，一般使用基于单点的 Redis 实现分布式锁就可以，出现数据不一致，通过人工手段去回补。
>

使用 Redis 快速实现分布式锁

# Go排序

Tags: Golang


![Untitled.png](https://cdn.jsdelivr.net/gh/Gypsophila1006/img/img/84469885cb1c2f6ac4a42fbc608877d9.Untitled.webp)

# 选择排序

每次找未排序部分最小的，放到前面

```go
func selectSort(arr []int) []int {
	for i := 0; i < len(arr); i++ {
		min := i
		for j := i + 1; j < len(arr); j++ {
			if arr[j] < arr[min] {
				min = j
			}
		}
		arr[i], arr[min] = arr[min], arr[i]
	}
	return arr
}
```

# 冒泡排序

比较相邻元素，如果逆序则交换

```go
func bubbleSort(arr []int) []int {
	swapped := true
	for swapped {
		swapped = false
		for i := 0; i < len(arr)-1; i++ {
			if arr[i] > arr[i+1] {
				arr[i], arr[i+1] = arr[i+1], arr[i]
				swapped = true
			}
		}
	}
	return arr
}
```

# 插入排序

将未排序的部分，逐个插入到已排序部分

```go
func insertSort(arr []int) []int {
	for i := 1; i < len(arr); i++ {
		tmp := arr[i]
		j := i - 1
		for ; j >= 0 && arr[j] > tmp; j-- {
			arr[j+1] = arr[j]
		}
		arr[j+1] = tmp
	}
	return arr
}
```

# 希尔排序

把记录按下标的一定增量分组，对每组使用直接插入排序算法排序；随着增量逐渐减少，每组包含的关键词越来越多，当增量减至 1 时，整个文件恰被分成一组，算法便终止。

```go
func shellSort(arr []int) []int {
	for d := len(arr) / 2; d > 0; d /= 2 {
		for i := d; i < len(arr); i++ {
			for j := i; j >= d && arr[j] < arr[j-d]; j -= d {
				arr[j], arr[j-d] = arr[j-d], arr[j]
			}
		}
	}
	return arr
}
```

# 归并排序

分治思想，不断将已排序的数组合并

```go
func merge(left, right []int) []int {
	res := make([]int, 0, len(left)+len(right))
	i, j := 0, 0
	for i < len(left) && j < len(right) {
		if left[i] <= right[j] {
			res = append(res, left[i])
			i++
		} else {
			res = append(res, right[j])
			j++
		}
	}
	for i < len(left) {
		res = append(res, left[i])
		i++
	}
	for j < len(right) {
		res = append(res, right[j])
		j++
	}
	return res
}

func mergesort(arr []int) []int {
	if len(arr) < 2 {
		return arr
	}
	mid := len(arr) / 2
	left := mergesort(arr[:mid])
	right := mergesort(arr[mid:])
	return merge(left, right)
}
```

# 快速排序

选出一个基准（pivot），将比它小的放在前面，大的放在后面。再递归的处理前后的数组

```go
func partition(list []int, low, high int) int {
	pivot := list[low]
	for low < high {
		for low < high && list[high] >= pivot {
			high--
		}
		list[low] = list[high]
		for low < high && list[low] <= pivot {
			low++
		}
		list[high] = list[low]
	}
	list[low] = pivot
	return low
}

func quickSort(list []int, low, high int) {
	if high > low {
		pivot := partition(list, low, high)
		quickSort(list, low, pivot-1)
		quickSort(list, pivot+1, high)
	}
}
```

Go排序

在这里，我记录学习后端技术、实习经验和个人思考，也会随性分享一些生活琐事和吐槽。如果你和我有相似的兴趣或经历，欢迎随时交流！