为什么会有atomic.LoadInt32

前些天我们聊了 Golang 内存对齐的话题,后来我突然想到另一个问题:为什么会有 atomic.LoadInt32?可能你觉得思维太跳跃了,容我慢慢道来:首先,有 atomic.LoadInt64 很正常,因为对一个 int64 来说,它的大小是 8 个字节,如果是 32 位平台的话(字长 4 字节),CPU 一次最多操作 4 个字节,需要两次才能拿到全部数据,所以封装一个 atomic.LoadInt64 来实现原子操作;但是,对一个 int32 数据来说,它的大小是 4 字节,不管是 32 位平台(字长 4 字节),还是 64 位平台(字长 8 字节),CPU 应该都可以保证一次操作拿到数据,换句话说,如果读取一个 int32 数据,那么本身就应该是原子的,可是为什么会有 atomic.LoadInt32,这不是脱了裤子放屁么?

继续阅读

浅谈Golang内存对齐

如果你在 golang spec 里以「alignment」为关键字搜索的话,那么会发现与此相关的内容并不多,只是在结尾介绍 unsafe 包的时候提了一下,不过别忘了字儿越少事儿越大:

Computer architectures may require memory addresses to be aligned; that is, for addresses of a variable to be a multiple of a factor, the variable’s type’s alignment. The function Alignof takes an expression denoting a variable of any type and returns the alignment of the (type of the) variable in bytes. For a variable x:

uintptr(unsafe.Pointer(&x)) % unsafe.Alignof(x) == 0

The following minimal alignment properties are guaranteed:

  • For a variable x of any type: unsafe.Alignof(x) is at least 1.
  • For a variable x of struct type: unsafe.Alignof(x) is the largest of all the values unsafe.Alignof(x.f) for each field f of x, but at least 1.
  • For a variable x of array type: unsafe.Alignof(x) is the same as the alignment of a variable of the array’s element type.

当然,如果你以前没有接触过内存对齐的话,那么对你来说上面的内容可能过于言简意赅,在继续学习之前我建议你阅读以下资料,有助于消化理解:

继续阅读

手把手教你用TARS

在中国,有一个简单的方法可以用来判断一个互联网公司够不够大,那就是看其是否开源过 rpc 框架!比如阿里巴巴的 dubbo,或者腾讯的 tars,小公司往往会对这些大公司的产品趋之若鹜,不过一个可悲的现实是大公司自己往往并不用他们开源的版本,这就好比皇帝总是把自己看不上眼的女人赏赐给臣民,不过能得到皇帝的赏赐总是好事,下面让我手把手教你用 tars,更具体的说是 tarsgo,也就是 tars 的 golang 实现。

继续阅读

记又一次对Makefile的重构

我平常有一个习惯,就是不断看以前写的代码,想着有没有哪些方面可以改进,如果每天能把代码可读性量变​ 1%,那么日积月累就是质变:前些天我们写过一次对 Makefile 的重构,去掉了一处重复代码的坏味道,没过多久我便又发现了一处重复代码的坏味道,本文就让我们看看如何消灭它!

继续阅读