分类 "Golang" 下的文章

公司大量使用微服务框架 go-micro,但框架作者已不再维护低版本(新版本已经商业化),只能自己动手了。

起因是我用 Go 1.16 编译,启动报错:

panic: qtls.ConnectionState not compatible with tls.ConnectionState

goroutine 1 [running]:
github.com/lucas-clemente/quic-go/internal/handshake.init.0()
        /go/pkg/mod/github.com/lucas-clemente/quic-go@v0.12.1/internal/handshake/unsafe.go:17 +0x118

跟进去看:

func init() {
    if !structsEqual(&tls.ConnectionState{}, &qtls.ConnectionState{}) {
        panic("qtls.ConnectionState not compatible with tls.ConnectionState")
    }
    if !structsEqual(&tls.ClientSessionState{}, &qtls.ClientSessionState{}) {
        panic("qtls.ClientSessionState not compatible with tls.ClientSessionState")
    }
}

发现 tls.ConnectionState 在是标准库的包 crypto/tls,也就是说,新版本的 Go 标准库的定义,和 github.com/marten-seemann/qtls 不兼容。

公司使用 Go 1.14 编译,程序是正常运行的。

翻了一大圈资料,都是让我降级版本:
https://github.com/ipfs/go-ipfs/issues/7597
https://segmentfault.com/a/1190000020124701
https://www.jianshu.com/p/253d08c50c44
https://www.cnblogs.com/huay/p/14491557.html
https://blog.csdn.net/Xiang_lhh/article/details/113814742

还真不能降版本!因为我电脑是 M1 芯片,必须使用 Go 1.16,只能硬着头皮改了。

翻了 go-micro 源码,Transport 定义了客户端和服务端的通信接口,支持 http、grpc、quic 等协议。

引用 外部 的一张 go-micro 架构图:

go-micro 架构图

我也搜到了一片文章,解释 QUIC 到底是个啥:

干货 | HTTP探索之路(一)- HTTP1/HTTP2/QUIC
https://zhuanlan.zhihu.com/p/102517430

言归正传,既然是 quic 不兼容标准库,那我们升级一下不就完了:

github.com/lucas-clemente/quic-go v0.12.1 -> v0.22.0

发现编译不通过——好家伙,新包直接改了接口定义!

对比了官方的更新,也就换了个方法名和包名,细节就不展开了,直接看我修复的代码吧:

https://github.com/Lofanmi/go-micro/commit/68bbf601cfa46b0c49c67f51e4e38e6a6f029f42

用法很简单,直接 replace 掉就 OK 了!

replace (
    github.com/micro/go-micro => github.com/Lofanmi/go-micro v1.16.1-0.20210804063523-68bbf601cfa4
)

如果还不行,再 replace 掉下面的包:

replace (
    github.com/golang/protobuf => github.com/golang/protobuf v1.3.2
    google.golang.org/genproto => google.golang.org/genproto v0.0.0-20191216164720-4f79533eabd1
    google.golang.org/grpc v1.30.0 => google.golang.org/grpc v1.26.0
    google.golang.org/protobuf => google.golang.org/protobuf v1.25.0
)

上面四个 replace 是工程内其他依赖的,我没办法测试只替换 go-micro 是否可以解决问题,所以也贴在这里,需要请自取哈。

阅读本文大约需要 40 分钟。

上一篇文章 《大白话讲讲 Go 语言的 sync.Map(一)》 讲到 entry 数据结构,原因是 Go 语言标准库的 map 不是线程安全的,通过加一层抽象回避这个问题。

当一个 key 被删除的时候,比如李四销户了,以前要撕掉小账本,现在可以在大账本上写 expunged,

对,什么也不写也是 OK 的。也就是说,

entry.p 可能是真正的数据的地址,也可能是 nil,也可能是 expunged。

为什么无端端搞这个 expunged 干嘛?因为 sync.Map 实际上是有两个小账本,

一个叫 readOnly map(只读账本),一个叫 dirty map(可读、也可写账本):

type Map struct {
    mu sync.Mutex
    read atomic.Value // readOnly
    dirty map[interface{}]*entry
    misses int
}

type readOnly struct {
    m       map[interface{}]*entry
    amended bool // true if the dirty map contains some key not in m.
}

既然有账本一个变成两个,那肯定会有些时候出现两个 map 数据是不一致的情况。

readOnly 结构的 amended 字段,是一个标记,为 true 的时候代表 dirty map 包含了一些 key,这些 key 不会存在 readOnly map 中。

这个字段的作用,在于加速查找的过程。

假设 readOnly 账本上有 张三、李四、钱五,dirty 账本除了这三个人,后面又新增了 王六,查找逻辑就是这样的:

  1. 先在 readOnly 查找,王六不在
  2. 判断 amended ,发现两个账本数据是不一致的
  3. 再去 dirty 账本查找,终于找到王六

如果 2 的 amended 标记是两个账本数据一致,那就没有执行 3 的必要了。

我们可以看看源码是怎么实现的:

func (m *Map) Load(key interface{}) (value interface{}, ok bool) {
  read, _ := m.read.Load().(readOnly)
  // 1. 先在 readOnly 查找,王六不在
  e, ok := read.m[key]
  // 2. 判断 amended ,发现两个账本数据是不一致的
  if !ok && read.amended {
    // 加锁的原因是,前面步骤 1 的读取有可能被另一个协程的 missLocked 更改了
    // 导致读出来的值不符合预期,所以加锁再读取一次,老套路了。
    m.mu.Lock()
    read, _ = m.read.Load().(readOnly)
    e, ok = read.m[key]
    if !ok && read.amended {
      // 3. 再去 dirty 账本查找,终于找到王六
      e, ok = m.dirty[key]
      // missLocked 拥有一个计数器,
      // 它的作用在于 readOnly 如果一直查不到,经常退化到 dirty,
      // 那就把 dirty 作为 readOnly ,直接取代它。
      m.missLocked()
    }
    m.mu.Unlock()
  }
  if !ok {
    return nil, false
  }
  return e.load() // 还记得大账本吗?这里是拿到最终的值,针对 entry.p == expunged 做了特殊处理。
}

func (m *Map) missLocked() {
  // 查不到就递增 misses 计数器
  m.misses++
  // 这个判断条件不是常数,而是 dirty map 的记录数。
  // 这个判断条件很奇妙,
  // 它使得 dirty 取代 readOnly 的时机,和 dirty 的数据量正相关了。
  // 也就是说,dirty map 越大,对两个 map 不一致的容忍度越大,
  // 不会有频繁的取代操作。
  if m.misses < len(m.dirty) {
    // 如果不是经常查不到,说明 readOnly 还是可以用的,退出。
    return
  }
  // 如果 readOnly 已经没有存在价值,那就把 dirty 取代 readOnly。
  // 此时,dirty 置空,并把 misses 计数器置 0。
  // read 和 dirty 的数据类型都是 map[interface{}]*entry,
  // 可以直接替换,无需类型转换,这个设计简直完美。
  m.read.Store(readOnly{m: m.dirty})
  m.dirty = nil
  m.misses = 0
}

func (e *entry) load() (value interface{}, ok bool) {
  p := atomic.LoadPointer(&e.p)
  // entry.p 可能是真正的数据的地址,也可能是 nil,也可能是 expunged
  if p == nil || p == expunged {
    // nil 或者是 expunged 都是不存在的,返回空
    return nil, false
  }
  // 如果是真正的数据地址,那就返回真正的数据(就是拿到大账本的某一页纸上的内容)
  return *(*interface{})(p), true
}

到这里已经讲完数据读取这部分的代码了,接着再讲数据是怎么写入的。

上一篇文章我留了一个思考题,

为什么小账本不能做到同时修改?限于篇幅,我不会展开。

我现在解答我们有了大账本,是如何做到同时修改的!

答案在这里:

// tryStore 顾名思义,就是不断尝试的意思。
// 你可以看到有一个无条件的死循环,只有某些条件满足的时候才会退出
// 计算机术语:自旋(自己一直在旋转)
func (e *entry) tryStore(i *interface{}) bool {
  for {
    p := atomic.LoadPointer(&e.p)
    // readOnly map 存储的是 entry 结构,p 就是所谓的大账本,
    // p 指向大账本上某一页纸上的内容,
    // 当账本查不到的时候,返回查不到。
    if p == expunged {
      return false
    }
    // 当账本可以查到的时候,使用 CAS 把旧的值,替换为新的值。
    // 可以查到并替换成功,返回成功,函数退出
    // 查不到或者替换失败,自旋,重试,直到成功为止
    if atomic.CompareAndSwapPointer(&e.p, p, unsafe.Pointer(i)) {
      return true
    }
  }
}

问题来了, CAS(Compare and Swap,比较并交换)是什么东西?我们看这个加法函数:

func add(delta int32) {
  for {
    // 把原先的值取出来
    oldValue := atomic.LoadInt32(&addr)
    // 读取后,如果没有其他人对它修改(Compare)
    // 那就用 oldValue+delta 新值,替换掉原来的值(Swap)
    // 成功程序退出,失败了就自旋重试(可能被其他人改了导致 Compare 不成功)
    if atomic.CompareAndSwapInt32(&addr, oldValue, oldValue+delta) {
      return
    }
  }
}

越来越有趣了,atomic.CompareAndSwapInt32 到底是个啥子哟?

它的具体实现在 src/runtime/internal/atomic/asm_amd64.s 里(不同 CPU 架构,使用的文件不同,这里以最常见的 amd64 为例):

// bool Cas(int32 *val, int32 old, int32 new)
// Atomically:
//  if (*val == old) {
//    *val = new;
//    return 1;
//  } else
//    return 0;
TEXT runtime∕internal∕atomic·Cas(SB),NOSPLIT,$0-17
  MOVQ  ptr+0(FP), BX
  MOVL  old+8(FP), AX
  MOVL  new+12(FP), CX
  LOCK
  CMPXCHGL  CX, 0(BX)
  SETEQ  ret+16(FP)
  RET

FP(Frame pointer: arguments and locals):

函数的输入参数,格式 symbol+offset(FP),symbol 没有实际意义,只为了增强代码可读性,但没有 symbol 程序无法编译。

ptr+0(FP) 代表第一个参数,取出复制给 BX 寄存器。

由于 ptr 是一个指针,在 64 位的处理器中,一个指针的占 8 个字节,

所以第二个参数 old+8(FP),偏移量 offset 等于 8,

而第三个参数 new+12(FP),偏移量再加 4 的原因是 int32 占据 4 个字节。

LOCK 指令前缀会设置处理器的 LOCK# 信号,锁定总线,阻止其他处理器接管总线访问内存,

设置 LOCK# 信号能保证某个处理器对共享内存的独占使用。

CMPXCHGL CX, 0(BX) 是比较并交换的指令,将 AX 和 CX 比较,相同将 BX 指向的内容 放入 CX,

CMPXCHGL 暗中使用了 AX 寄存器。

兜了一大圈,终于明白大账本的数据是怎样被更新的了。

看看数据是怎么写入之前,我们要知道数据是怎么被删除的:

// 删除的逻辑是比较简单的。
func (m *Map) LoadAndDelete(key interface{}) (value interface{}, loaded bool) {
  read, _ := m.read.Load().(readOnly)
  e, ok := read.m[key]
  // key 不存在的时候并且 readOnly map 和 dirty map 不一致时,
  // 把 dirty map 对应的记录删了。
  if !ok && read.amended {
    m.mu.Lock()
    read, _ = m.read.Load().(readOnly)
    e, ok = read.m[key]
    if !ok && read.amended {
      // 数据不一致的时候,最终读出来的值以 dirty map 为主,
      // 即使 readOnly map 是 !ok 的,但 dirty map 可能是 ok 的,
      // 既然值可能是存在的,那就读取出来。
      e, ok = m.dirty[key]
      // 删除操作
      delete(m.dirty, key)
      // 递增数据不一致的计数器。
      // 太多不一致会把 dirty map 提升为 readOnly map,前面讲过了。
      m.missLocked()
    }
    m.mu.Unlock()
  }
  // key 存在的时候,把 key 置为 nil,注意这里不是 expunged,
  // 这也是我为什么要先讲 Delete 的原因。
  if ok {
    return e.delete()
  }
  return nil, false
}

// Delete deletes the value for a key.
func (m *Map) Delete(key interface{}) {
  m.LoadAndDelete(key)
}

// delete 将对应的 key 置为 nil!而不是 expunged!
func (e *entry) delete() (value interface{}, ok bool) {
  for {
    p := atomic.LoadPointer(&e.p)
    if p == nil || p == expunged {
      return nil, false
    }
    if atomic.CompareAndSwapPointer(&e.p, p, nil) {
      return *(*interface{})(p), true
    }
  }
}

OK,我们看数据写入的逻辑,它是整个源码中最难理解的,隐含的逻辑关系非常多:

// unexpungeLocked 将 expunged 的标记变成 nil。
func (e *entry) unexpungeLocked() (wasExpunged bool) {
  return atomic.CompareAndSwapPointer(&e.p, expunged, nil)
}

// storeLocked 将 entry.p 指向具体的值
func (e *entry) storeLocked(i *interface{}) {
  atomic.StorePointer(&e.p, unsafe.Pointer(i))
}
// tryExpungeLocked 尝试 entry.p == nil 的 entry 标记为删除(expunged)
func (e *entry) tryExpungeLocked() (isExpunged bool) {
  p := atomic.LoadPointer(&e.p)
  // for 循环的作用,可以保证 p != nil,
  // 保证写时复制过程中,p == nil 的情况不会被写到 dirty map 中。
  for p == nil {
    if atomic.CompareAndSwapPointer(&e.p, nil, expunged) {
      return true
    }
    p = atomic.LoadPointer(&e.p)
  }
  return p == expunged
}

// dirtyLocked 写时复制,两个 map 都找不到新增的 key 的时候调用的。
func (m *Map) dirtyLocked() {
  // dirty 被置为 nil 的情景还记得吗?
  // 
  // 当 readOnly map 一直读不到,需要退化到 dirty map 读取的时候,
  // dirty map 会被提升为 readOnly map,
  // 此时,dirty map 就会被置空。
  //
  // 但是,dirtyLocked 被调用之前,
  // 都是判断 read.amended 是否为 false
  // if !read.amended {...}
  // 个人认为,可以直接判断 if m.dirty == nil {...},
  // 代码可读性更强!下面三行代码也可以不要了。
  if m.dirty != nil {
    return
  }
  // 遍历 readOnly map,把里面的内容都复制到新创建的 dirty map 中。
  read, _ := m.read.Load().(readOnly)
  m.dirty = make(map[interface{}]*entry, len(read.m))
  for k, e := range read.m {
    // tryExpungeLocked 将 entry.p == nil 设置为 expunged,
    // 遍历之后,所有的 nil 都变成 expunged 了。
    // 返回 false 说明 p 是有值的,要拷贝到 dirty 里。
    // Delete 操作会把有值的状态,转移为 nil,
    // 并不会把 expunged 状态转移为 nil,
    // 由于 for 循环的存在,p 也不会等于 nil,
    // 也就是说,tryExpungeLocked 的 p == expunged 是可以信任的。
    if !e.tryExpungeLocked() {
      // 如果没有被删除,拷贝到 dirty map 中。
      m.dirty[k] = e
    }
  }
}

func (m *Map) Store(key, value interface{}) {
  // 如果 readOnly map 有对应的 key,
  // 通过 e.tryStore 直接写入(就是上面更新大账本的整个过程),
  // 注意,tryStore 会在 entry.p == expunged 的情况下失败。
  read, _ := m.read.Load().(readOnly)
  if e, ok := read.m[key]; ok && e.tryStore(&value) {
    return
  }
  // readOnly map 找不到,或者 key 被删除了,
  // 那就写到 dirty map 里面。
  m.mu.Lock()
  read, _ = m.read.Load().(readOnly)
  if e, ok := read.m[key]; ok {
    // unexpungeLocked 将 expunged 的标记变成 nil。
    // 当 entry.p == expunged,并且成功替换为 nil,
    // 返回 true。
    // 
    // 这个分支的意义在于,写时复制 dirtyLocked 的时候,
    // 数据从 readOnly map 搬迁到 dirty map 中,
    // 如果 p 是被删除的,dirty 是不会有这个 key 的,
    // 所以要把它也写进 dirty 中,保证数据的一致性。
    // 
    // 为什么好端端的 expunged,要改成 nil?
    // unexpungeLocked 是一个原子操作,成功的话,
    // 说明 p == expunged,
    // 说明写时复制已经完成。
    // 
    // 为什么要写时复制完成之后,才可以去改 dirty?
    // 我理解是这样的:
    // 如果不这样做,dirty 会被你修改成 Store 传进来的参数,
    // 写时复制又把它修改成 readOnly map 的值,
    // 所以更新 readOnly map 就好了。
    // 
    // 这一块的细节真的非常多,每一块地方都要小心处理好。
    if e.unexpungeLocked() {
      m.dirty[key] = e
    }
    // 写入值。
    e.storeLocked(&value)
  } else if e, ok := m.dirty[key]; ok {
    // 如果 dirty map 存在就直接更新进去,这个很好理解,
    // 因为 readOnly map 找不到会来 dirty 查。
    e.storeLocked(&value)
  } else {
    // 两个 map 都找不到的时候,说明这是一个新的 key。
    // 
    // 1. 如果 dirty 之前被提升为 readOnly,那就导一份没有被删除的 key 进来。
    // 
    // 这个判断条件,我理解等价于 if m.dirty == nil {...}
    if !read.amended {
      // 初始化 m.dirty,并把值写进去(写时复制)
      m.dirtyLocked()
      // amended 设置为不一致。
      // amended 表示 dirty 是否包含了 readOnly 没有的记录,
      // 很明显,read.m[key] 是 !ok 的,
      // 下面把值存到 dirty map 里面了。
      m.read.Store(readOnly{m: read.m, amended: true})
    }
    // 2. 这里,把值存到 dirty map 中。
    m.dirty[key] = newEntry(value)
  }
  m.mu.Unlock()
}

精妙绝伦!整个写入的逻辑就讲完了,最后看看遍历吧,非常简单:

func (m *Map) Range(f func(key, value interface{}) bool) {
  read, _ := m.read.Load().(readOnly)
  // 如果不一致,就把 dirty 提升为 readOnly,
  // 同时 dirty 置空,
  // 因为 dirty map 也包含了 readOnly map 没有的 key。
  if read.amended {
    m.mu.Lock()
    read, _ = m.read.Load().(readOnly)
    if read.amended {
      read = readOnly{m: m.dirty}
      m.read.Store(read)
      m.dirty = nil
      m.misses = 0
    }
    m.mu.Unlock()
  }
  // 遍历 readOnly map 的数据,执行回调函数。
  for k, e := range read.m {
    v, ok := e.load()
    if !ok {
      continue
    }
    if !f(k, v) {
      break
    }
  }
}

好了,到这里整个 sync.Map 就讲完了,剩下的代码也没多少了,套路差不多,我们总结一下:

  1. 在读多写少的场景下,sync.Map 的性能非常高,因为访问 readOnly map 是无锁的;
  2. Load:先查找 readOnly map,找不到会去找 dirty map,如果经常没命中,dirty map 会被提升为 readOnly map,提升的时机跟 dirty 的大小相关,dirty 越大,容忍不命中的次数就越多,也就越难提升;
  3. Delete:当 readOnly map 的 key 不存在的时候,会去删除 dirty map 中的 key;如果 readOnly map 的 key 存在,entry.p 置为 nil;
  4. Store :

    1. readOnly map 的 key 存在时,entry.p != expunged 时直接更新,entry.p == expunged 就改成 nil,此时数据也同步写入 dirty map;
    2. readOnly map 的 key 不存在时,dirty map 有就更新进去,两个都没有,触发写时复制机制:搬迁 readOnly map 的没有被删除的 key 到 dirty map 中,新值写入 dirty map,并设置 amended 标记为 true。
  5. sync.Map 的缺陷在于读少写多的时候,dirty map 会被一直更新,misses 次数增加,dirty 置空后,数据又重新从 readOnly map 同步回去,使得 sync.Map 忙于数据搬迁工作,影响性能。

这篇文章近 5000 字(第一篇差不多 2000 字),从构思、成文到校对,真的需要花费不少时间,希望对你有帮助!

阅读本文大约需要 4.25 分钟。

程序是枯燥乏味的。

在讲 sync.Map 之前,我们先说说什么是 map(映射)。

我们每个人都有身份证号码,如果我需要从身份证号码查到对应的姓名,用 map 存储是非常合适的。

map[000...001] = 张三
map[000...002] = 李四
...
map[999...993] = 钱五

身份证号码有 18 位,如果要知道 111...002 这个人叫什么名字,没有 map 我只能从 000...001 一个一个往下查找,效率是非常低的。

咦,那 map 不就是在查字典嘛?根据拼音、笔画、部首,可以查到某个字的具体含义!

没错!Go 语言中的 map 在 Python 语言称之为 dict(字典),意思是完全一样的。

再设想另一个场景,

如果 map 存储的是每个人银行卡里的余额(同一所银行),那就是这样子的形式(账本):

map[张三] = 100.00
map[李四] = 600.00
map[钱五] = 800.00

某一天,李四要转账给张三和钱五,各 100 元,银行为了提高转账速度,安排了两名交易员同时处理。

交易员 A 和交易员 B 瞄了一眼账本,开始操作:

交易员 A:李四的余额是 600 元,张三的余额是 100 元,转账后李四的余额是 500 元,张三的余额是 200 元。
交易员 B:李四的余额是 600 元,钱五的余额是 800 元,转账后李四的余额是 500 元,钱五的余额是 900 元。

账本变成这个样子:

map[张三] = 200.00
map[李四] = 500.00
map[钱五] = 900.00

账本出问题了!银行凭空多出 100 元!

一个一个来不就完了?可是你别忘了,我们是为了提高转账速度,才这样做的。

在 Go 1.9 之前,大部分人还真的就是这么干的!

type Name        string
type Money       string
type AccountBook struct {
    lock sync.RWMutex
    m    map[Name]Money
}

sync.RWMutex 是一个读写锁,在写入数据的时候,阻止其他人写入、读取,让其他人处于等待的状态,直到操作完再释放锁。

本质上,上面的例子,就是读取到了脏数据,如果能等待交易员 A 把账本改完,交易员 B 再去操作,账本就不会乱了。

如果你不知道锁是什么,我再给你讲一个例子:

张三和李四两个人,需要打印不同的文档,

打印机只有一台,放在打印室里,打印室有钥匙,

钥匙只有一把,谁拿到打印室的钥匙,谁就能进去打印。

打印室的钥匙,就是锁。

张三拿了钥匙,进去打印室,打印完了,就出来后把钥匙给了李四,李四打印完了把钥匙还回打印室(真是有条不紊)。

我花费这么多笔墨说 map,也是真的希望,就算你不是程序员,不是 Go 语言后端工程师,也可以看懂我的文章。

不得不承认,把复杂琐碎的东西,讲通透、讲明白是一种本事。

教科书讲 if...else、switch、while (true) 、异常和捕获,

如果有下面的图片这么形象生动就好了:

看到图片的那一瞬间,真的把我逗乐了。

多么形象生动啊!

回头想想,大学的 C 语言课程是多少人的噩梦,老师都是照书念的,完全听不进去。

我也不感慨了,咱们还是回归正题。

刚刚讲了 map,接着往下讲 sync.Map,它用来解决什么问题?

我们知道 map + 锁的形式,还是有等待的现象出现,不符合我们提高转账速度的初衷。

而 sync.Map 有一个非常巧妙的抽象(entry 的 p 指向具体数据的位置):

var m map[key]*entry

type entry struct {
    p unsafe.Pointer
}

还是看回上面的例子,做个小修改——原先的 map 是一个小账本,我们又做了一个大账本,原先的账本变成:

map[张三] = 记录在大账本第 6 页(翻开第 6 页,内容是:100.00)
map[李四] = 记录在大账本第 7 页(翻开第 7 页,内容是:600.00)
map[钱五] = 记录在大账本第 8 页(翻开第 8 页,内容是:800.00)

假设小账本 map 的张三、李四只能一个一个排队改,没办法做到同时修改,

而我们有了大账本,可以直接同时修改张三、李四纸上的内容(两页纸互不影响了)。

(真实的计算机世界确实如此,具体是怎么样的,留一个思考题,下一篇文章细细解答)

更通俗的讲,sync.Map 通过 entry 这个中间层的抽象,

把最开始整个小账本的冲突(影响所有人),降低到大账本上的某一页纸(只影响某个人),

用计算机术语讲,就是降低锁的粒度,从而提升性能!

另一方面,假设李四销户了,

我可以选择在第 7 页的纸上写,已销户(expunged),

// expunged is an arbitrary pointer that marks
// entries which have been deleted from the 
// dirty map.
var expunged = unsafe.Pointer(new(interface{}))

如果是以前,只能把小账本,李四那一张纸撕掉,

而撕掉小账本的某一页,也会影响所有人使用小账本,

如果下次要把撕掉的那一页放回去,也是非常麻烦,

在计算机的世界里,这是资源的分配和回收的问题,会严重影响程序运行效率。

写了一千七百字,直到现在只是冰山一角,sync.Map 的巧妙之处,远远不止 entry 的抽象。

今天先消化这么多,下一篇文章会更深层次一些,敬请期待!

今天分享的内容比较基础,准确地说是 Go 的语言特性——命名、匿名返回值。

先看下面的例子,猜测会输出什么?

package main

func main() {
    println(A())
    println(B())
}

func A() int {
    var i int
    defer func() {
        i = i + 3
    }()
    return i
}

func B() (i int) {
    defer func() {
        i = i + 3
    }()
    return i
}

|

(想好答案再滑下来)

|

|

|

|

|

|

|

|

|

|

正确答案:0 3。

A 和 B 两个函数的区别在于,B 的函数返回值是命名的,所以 defer 函数执行的修改,会作用到 B 本身;

而 A 函数返回值是匿名的,取决于 return 的时候求出来的值。

翻遍整个 GitHub , Golang 中文转拼音类库, 怎么就这么难找呢? 于是我造了一个轮子: 中文转拼音类库. 目前来说应该是最好用的了.

GitHub 传送门: https://github.com/Lofanmi/pinyin-golang

如果说基于汉字拼音字典, 逐个汉字替换, 也是可以转换的, 但是碰到多音字就很麻烦了. 而基于词库, 最起码可以解决大多数的多音字的转换, 人名姓氏的转换.

最开始我用了 CC-CEDICT 词典, 基于词组的长度, 以及英文释义的丰富程度, 来决定替换的优先级, 词组越长优先替换, 英文解释越丰富, 说明它越常用, 拥有更高的优先级, 后来发现它很多汉字都没有收录, 更别说生僻字了.

现在我把 安正超 的 PHP 开源项目 overtrue/pinyin 中的词库搬过来, 整理成一个 []string 放在 go 文件里面, 978K , 编译完也不需要依赖词库了, 非常符合 Go 的气质.

当然也不能说它可以解决 100% 的转换, 多多少少肯定会有瑕疵, 但是问题不大, 完善好词库, 对付一般的转换是绝对没问题的. 如果想完全解决, 词库定会无比庞大...

用法很简单, 接口都很清晰, 不再赘述.

INSTALL

go get -u -v github.com/Lofanmi/pinyin-golang/pinyin

DEMO

package main

import (
    "fmt"

    "github.com/Lofanmi/pinyin-golang/pinyin"
)

func main() {
    dict := pinyin.NewDict()

    // ----
    // 简单用法
    // ----

    // Redis shì yí gè Key-Value cún chǔ xì tǒng.
    str := `Redis 是一个 Key-Value 存储系统。`
    fmt.Println(dict.Sentence(str).Unicode())

    s := ""

    // wǒ hé shí néng bào fù
    s = dict.Convert(`我,何時能暴富?`, " ").Unicode()
    fmt.Println(s)
    // wǒ, hé shí néng bào fù?
    s = dict.Sentence(`我,何時能暴富?`).Unicode()
    fmt.Println(s)

    // ----
    // 转换接口: Dict.Convert
    // ----

    // 输入繁体中文, 输出为带 空格 分隔的拼音字符串
    // ASCII 格式显示
    // wo3 he2 shi2 neng2 bao4 fu4
    s = dict.Convert(`我,何時能暴富?`, " ").ASCII()
    fmt.Println(s)

    // 输入简体中文, 输出为带 连字符- 分隔的拼音字符串
    // Unicode 格式显示
    // wǒ-hé-shí-néng-bào-fù
    s = dict.Convert(`我,何时能暴富?`, "-").Unicode()
    fmt.Println(s)

    // 转换简体中文和繁体中文, 转换为带 斜杆/ 分隔的拼音字符串
    // 不显示声调
    // wo/he/shi/neng/bao/fu
    s = dict.Convert(`我,何时能暴富?`, "/").None()
    fmt.Println(s)

    // ----
    // 句子接口: Dict.Sentence
    // ----

    // 输入繁体中文, 输出为带 空格 分隔的拼音字符串
    // ASCII 格式显示
    // wo3, he2 shi2 neng2 bao4 fu4?
    s = dict.Sentence(`我,何時能暴富?`).ASCII()
    fmt.Println(s)

    // 输入简体中文, 输出为带 空格 分隔的拼音字符串
    // Unicode 格式显示
    // wǒ, hé shí néng bào fù?
    s = dict.Sentence(`我,何时能暴富?`).Unicode()
    fmt.Println(s)

    // 转换简体中文和繁体中文, 转换为带 空格 分隔的拼音字符串
    // 不显示声调
    // wo, he shi neng bao fu?
    s = dict.Sentence(`我,何时能暴富?`).None()
    fmt.Println(s)

    // ----
    // 转换人名: Dict.Name
    // ----

    // 输入繁体中文, 输出为带 空格 分隔的人名拼音字符串
    // ASCII 格式显示
    // mo4 qi2 wo4 xi3 huan1 chi1 suan1 nai3
    s = dict.Name(`万俟沃喜欢吃酸奶`, " ").ASCII()
    fmt.Println(s)

    // 输入简体中文, 输出为带 连字符- 分隔的人名拼音字符串
    // Unicode 格式显示
    // mò-qí-wò-xǐ-huan-chī-suān-nǎi
    s = dict.Name(`万俟沃喜欢吃酸奶`, "-").Unicode()
    fmt.Println(s)

    // 转换简体中文和繁体中文, 转换为带 斜杆/ 分隔的人名拼音字符串
    // 不显示声调
    // mo/qi/wo/xi/huan/chi/suan/nai
    s = dict.Name(`万俟沃喜欢吃酸奶`, "/").None()
    fmt.Println(s)

    // ----
    // 转换拼音简写: Dict.Abbr
    // ----

    // 转换简体中文和繁体中文, 输出为带 连字符- 分隔的拼音字符串首字符
    // m-q-w-x-h-c-s-n
    s = dict.Abbr(`万俟沃喜欢吃酸奶`, "-")
    fmt.Println(s)

    // ----
    // 转换为字符串 slice: ToSlice
    // ----
    // wo3 he2 shi2 neng2 bao4 fu4
    s = dict.Convert(`我,何時能暴富?`, " ").ASCII()
    fmt.Println(s)

    // [wo3 he2 shi2 neng2 bao4 fu4]
    fmt.Printf("%v", pinyin.ToSlice(s))

    // $ go run main.go
    // Redis shì yí gè Key-Value cún chǔ xì tǒng.
    // wǒ hé shí néng bào fù
    // wǒ, hé shí néng bào fù?
    // wo3 he2 shi2 neng2 bao4 fu4
    // wǒ-hé-shí-néng-bào-fù
    // wo/he/shi/neng/bao/fu
    // wo3, he2 shi2 neng2 bao4 fu4?
    // wǒ, hé shí néng bào fù?
    // wo, he shi neng bao fu?
    // mo4 qi2 wo4 xi3 huan1 chi1 suan1 nai3
    // mò-qí-wò-xǐ-huān-chī-suān-nǎi
    // mo/qi/wo/xi/huan/chi/suan/nai
    // m-q-w-x-h-c-s-n
    // wo3 he2 shi2 neng2 bao4 fu4
    // [wo3 he2 shi2 neng2 bao4 fu4]
}

Contribution

欢迎提意见及完善词库

License

MIT