久违

　　一眨眼，2021已经过去了3个月了，也很久没有写写blog了。
　　兴许是懒了，兴许是工作后也没有那么多时间和经历去维护blog。总而言之，久违了。
　　2021，怎么说呢，总感觉时间过得越来越快，有点越来越抓不住的感觉。
　　工作上，算是平平淡淡吧，前大半年算是非常忙吧，毕竟处于高强度研发阶段，后半年搬到高唐之后，节奏稍微慢下来，会轻松一丢丢。技术上学到了更多高大上的知识，对大ＤＡＵ项目的架构有了更清晰的认识和更近距离的了解。更加深入地学习了Python的各种知识，有一说一，Python对于业务来说，真的是神器啊，开发效率太杠杠了。
　　但是上帝打开一道门，就会关闭一扇窗。运行效率上就难顶了，唉，毕竟你都用python了，还在意什么运行效率？但是现实就是这么的魔幻。我们需要尽量兼顾两者，开发效率和运行效率，鱼与熊掌，二者均想兼得。
　　空闲时间，也用python搞了几个小玩意加深下技术。发现总喜欢捣鼓点小东西，但是要真正捣鼓小东西需要的时间和精力实在是有点多，加上工作又忙，渐渐地有点力不从心了。有时间想把一些小东西开下源，都懒得弄了。见识了公司泡泡和服务器的ｔｂ联动，于是也想搞搞，最终找到了飞书，不得不说，飞书也是很好用的一个东西，支持自定义消息，往指定的地址丢个数据，就能在手机端显示出来，以及接收手机端的输入，对于我的小玩意的监测实在是太好用了。以前写的小玩意，出了啥问题，只能是给邮箱地址发给邮件通知，实在是太麻烦了。打通了飞书的通知和交互逻辑之后，出了啥问题，都能反馈到飞书群上，同时还能直接输入指令给服务器接收，还是挺方便的。
　　生活上，也算是平平淡淡吧。老婆２０２０年６月左右换工作到了荔湾区，实在是说不想通勤太麻烦了，而且娃大部分时间也是老婆在带，只能是辛苦自己，于是搬到了荔湾区住。其实心里还是有点抵触的，毕竟之前我的通勤都控制在３０ｍｉｎ以内，一下子飙到了５０ｍｉｎ，实在是有点难顶。原本想法是２０２１把买房的事情定下来，但是从３月份开始看房一直看到年末，基本上广州的几个区都看过了，市区二手房老破小，３００ｗ以内的，基本上都是８０ｍ^2^，最低２０年以上房龄的，说真的，想想花那么多钱，买这种居住体验，实在是难以下手。说什么以后还会涨，后面继续换房，在我看来，机会真的不大。想换房至少５年后，５年后，房龄就已经２５年了，再想卖，想屁吃。为了给娃一个更好的学习环境？在我看来是个谬论，如果没有全方位的资源，特别是生活已经被房贷压住，怎么会有精力更好的养娃呢。其实我更希望地是有更多的时间陪伴，但是确实很多时候，我都在搞自己的东西，或者是在玩游戏，陪娃的时间确实是很少，这点也确实是经常被老婆和老妈埋怨。
　　中年男人，家庭地位实在是低。又要挣钱养家，又希望给更多时间给娃，又要每天忍受５０ｍｉｎ每趟的通勤，有时候实在是有点烦。搬到高唐之后，就直接自己开车去上班了，去班车那里实在是太远了，起码单趟要１ｈ３０ｍｉｎ，想想就可怕。
　　一不小心，把电脑踹了一下，死机了。１６６０ｓ的显卡只有一个ＨＤＭＩ接口，然而我的两个显示器都是ＨＤＭＩ的，只能是买了个ＤＰ转ＨＤＭＩ，只是那个转接头在主机背面如果不小心碰到就会死机，风扇死命地转，哎，只好重新调了下主机的位置，然后发现很干脆地，转接头貌似直接坏掉了，得勒，好走不送，直接入手一整条的转换线得了。
　　哎，又快００:３０了，还没洗澡呢，明天还得早起搬砖，先不写了吧。

新的开始

阿里云2核8G的机器，今年11月就要过期了，原本的博客基于wordpress，部署在阿里云的机器上，于是又动起了折腾的心思。

why is github+hexo

也想过是不是继续部署在腾讯云的2h4g或者1h2g的小机器上,(毕竟也是有好几台服务器的人呢，不过这两台小机器经常被我折腾，也不稳定，稍微稳定点的2h4g又被我部署了点小玩意上去，实在不太能撑得住wordpress，寻寻觅觅，了解到有基于github+hexo的静态网站部署方案，觉得不错，就上了。
也可能是因为年纪渐长，不像以前那么喜欢投入比较多的时间来钻研乱七八糟的东西了，打算弄个稳定点的博客来记录一下自己的一些学习、生活上的成长，加上一直用github，虽然经常被墙，但是对于搞技术的来说，就是偶尔有点小麻烦而已，其他的都挺好的。

踩坑了吗

开玩笑呢，搞新东西哪有不踩坑的。
hexo整体部署还是挺方便的，网上也挺多教程。
主要踩坑点是选主题以及配置评论系统
评论系统原本想用gitment这个方案的，但是由于gitment年久失修，以及选中主题作者也挺久没更新了，导致配置不上，也在自己的小机器部署了gh-oauth-server以及cros-anywhere服务，但是gitment搞了挺多次还是不行，先退而求其次，采用gitee的方案了。

展望

说实话最近几年都比较少更新自己的博客了，光顾着搞点乱七八糟的小玩意
未来打算先开源几个之前搞的小玩意，然后重新拾起写文章的习惯

just keep move ~~~

腾讯云的1核2G机器日渐不够用了，去年趁着阿里云优惠入手了一个2核8G，最近把腾讯云上的东西都迁到阿里云来。 记录一下。

最近接触了一下微信公众号开发，刚好很久很久之前申请过一个公众号，看了下API文档，用go实现了一个简单的验证微信服务器的功能。 下面的代码可以通过微信服务器的验证。 只需要配置 config.json文件即可,config.json和main.go文件处于同一目录层级，config.json格式文件配置如下:

{
“token”:”XXX”,
“port”:”7001”
}

其中token需要在微信公众平台获取相关信息。 port 则是你使用的监听接口，nginx反向代理到该端口。 运行时，输入 go run main.go config.json 即可 代码：

package main

import (
“crypto/sha1”
“encoding/json”
“fmt”
“io”
“io/ioutil”
“log”
“net/http”
“os”
“sort”
“strings”
)

const wx_params_timestamp string = “timestamp”
const wx_params_signature string = “signature”
const wx_params_nonce string = “nonce”
const wx_params_echostr string = “echostr”

const wx_access_token_key string = “access_token”
const wx_access_token_time_key string = “expires_in”

const wx_access_token_error_code string = “errcode”
const wx_access_token_error_msg string = “errmsg”

//
var wx_gzh_token_str string

type SConsConfig struct {
Token string `json:”token”`
Port string `json:”port”`
}

func NewJsonStruct() *SConsConfig {
return &SConsConfig{}
}

func (jst *SConsConfig) LoadConfig(fileName string, v interface{}) {
data, err := ioutil.ReadFile(fileName)
if err != nil {
return
}
err = json.Unmarshal(data, v)
if err != nil {
return
}
}
func ParseSconsConfig(fileName string) (v SConsConfig, err error) {
JsonParse := NewJsonStruct()
v = SConsConfig{}
JsonParse.LoadConfig(fileName, &v)
return v, nil
}

func makeSignature(timestamp string, nonce string) string {

//1. 将 plat_token、timestamp、nonce三个参数进行字典序排序
sl := []string{wx_gzh_token_str, timestamp, nonce}
sort.Strings(sl)
//2. 将三个参数字符串拼接成一个字符串进行sha1加密
s := sha1.New()
io.WriteString(s, strings.Join(sl, “”))

return fmt.Sprintf(“%x”, s.Sum(nil))
}

func CheckSignature(r *http.Request) (bool, string) {
r.ParseForm()
log.Println(“start parse require params”)
for k, v := range r.Form {
log.Println(“k=”, k, “,v=”, v)
}
timestamp := “”
if len(r.Form[wx_params_timestamp]) > 0 {
timestamp = r.Form[wx_params_timestamp][0]
log.Println(wx_params_timestamp, “=”, timestamp)
}
signature := “”
if len(r.Form[wx_params_signature]) > 0 {
signature = r.Form[wx_params_signature][0]
log.Println(wx_params_signature, “=”, signature)
}

nonce := “”
if len(r.Form[wx_params_nonce]) > 0 {
nonce = r.Form[wx_params_nonce][0]
log.Println(wx_params_nonce, “=”, nonce)
}

echostr := “”
if len(r.Form[wx_params_echostr]) > 0 {
echostr = r.Form[wx_params_echostr][0]
log.Println(wx_params_echostr, “=”, echostr)
}

my_signature := makeSignature(timestamp, nonce)
log.Println(“my signature is “, my_signature)

if signature == my_signature {
return true, echostr
} else {
return false, echostr
}
}

type wx_token_require_handler struct{}

func (h *wx_token_require_handler) ServeHTTP(w http.ResponseWriter, r *http.Request) {
log.Println(“check require is from wx server or not”)

flag, echostr := CheckSignature(r)

if flag {
w.Write([]byte(echostr))
} else {
log.Println(“require not from wx server,please check”)
}
}

func InitGlobal() {
wx_gzh_token_str = “”
}

func HttpCheckServer(checkPort string) {
http.Handle(“/“, &wx_token_require_handler{})
port := “0.0.0.0:” + checkPort
log.Println(“start listen port:”, checkPort)
http.ListenAndServe(port, nil)
}

func main() {

log.Println(“start gzh token center”)
log.Println(“param format: port srv_port”)

arg_num := len(os.Args)

if arg_num < 2 {
log.Println(“please input the port and token str”)
os.Exit(1)
}

configFile := os.Args[1]

config, err := ParseSconsConfig(configFile)

if nil != err {
log.Println(“parse config error,err=”, err)
os.Exit(1)
}
InitGlobal()
wx_gzh_token_str = config.Token

HttpCheckServer(config.Port)
}

最近接触了一下微信公众号开发，刚好很久很久之前申请过一个公众号，看了下API文档，用go实现了一个简单的获取 access_token的功能。 下面的代码可以从微信服务器获取access_tokens，并保存在内存中，然后其他程序可以通过http请求获取到内存中的 access_token，超时的时候，还会自动重新从微信服务器获取新的access_tokens。 只需要配置 config.json文件即可,config.json和main.go文件处于同一目录层级，config.json格式文件配置如下:

{
“appid”:”XXX”,
“secret”:”XXX”,
“token”:”XXX”,
“port”:”7001”
}

其中 appid,secret以及token需要在微信公众平台获取相关信息。 port 则是你使用的监听接口，即其他人通过这个接口获取access_tokens。 获取的方式是通过浏览器访问你的 url地址+/token 后缀。 运行时，输入 go run main.go config.json 即可 代码： main.go

package main

import (
“bytes”
“encoding/json”
“io/ioutil”
“log”
“net/http”
“os”
“time”
)

const wx_params_timestamp string = “timestamp”
const wx_params_signature string = “signature”
const wx_params_nonce string = “nonce”
const wx_params_echostr string = “echostr”

const wx_access_token_key string = “access_token”
const wx_access_token_time_key string = “expires_in”

const wx_access_token_error_code string = “errcode”
const wx_access_token_error_msg string = “errmsg”

//
var wx_gzh_token_str string
var wx_gzh_appid string
var wx_gzh_secret string

var global_access_token string
var global_access_token_time_out int64

type SConsConfig struct {
Appid string `json:”appid”`
Secret string `json:”secret”`
Token string `json:”token”`
Port string `json:”port”`
}

func NewJsonStruct() *SConsConfig {
return &SConsConfig{}
}

func (jst *SConsConfig) LoadConfig(fileName string, v interface{}) {
data, err := ioutil.ReadFile(fileName)
if err != nil {
return
}
err = json.Unmarshal(data, v)
if err != nil {
return
}
}
func ParseSconsConfig(fileName string) (v SConsConfig, err error) {
JsonParse := NewJsonStruct()
v = SConsConfig{}
JsonParse.LoadConfig(fileName, &v)
return v, nil
}

type wx_access_token_center_handler struct{}

func (h *wx_access_token_center_handler) ServeHTTP(w http.ResponseWriter, r *http.Request) {
log.Println(“somebody require token”)

current_time := time.Now().Unix()

if current_time > global_access_token_time_out {
log.Println(“token timetou ,require from wx………..”)
GetAccessToken(wx_gzh_appid, wx_gzh_secret)
} else {
log.Println(“token is valid,require from local”)
}
w.Write([]byte(global_access_token))
}

func ParseTokens(str string) {
decoder := json.NewDecoder(bytes.NewBufferString(str))
decoder.UseNumber()
var result map[string]interface{}
if err := decoder.Decode(&result); err != nil {
log.Println(“json parse failed,str=”, str, “\nerr=”, err)
os.Exit(1)
}
log.Println(“parse”, str, “json”)

if _, ok := result[wx_access_token_error_code]; ok {
log.Println(“error token,code=”, result[wx_access_token_error_code])
log.Println(“errmsg=”, result[wx_access_token_error_msg])
}

access_token := result[wx_access_token_key]
access_token_value, ok := access_token.(string)
if !ok {
log.Println(“parse access_token failed,access_token=”, access_token)
}
log.Println(“access_token_value:”, access_token_value)

time_num := result[wx_access_token_time_key]
time_num_value, err := time_num.(json.Number).Int64()
if err != nil {
log.Println(“parase time_num failed,time_num=”, time_num)
}
log.Println(“time:”, time_num_value)

current_time := time.Now().Unix()

global_access_token = access_token_value
global_access_token_time_out = current_time + time_num_value

formatTimeStr := time.Unix(global_access_token_time_out, 0).Format(“2006-01-02 15:04:05”)

log.Println(“success parse json,token will be timeout at “, global_access_token_time_out, “,”, formatTimeStr)
}

func GetAccessToken(appid string, secret string) {

params := “/cgi-bin/token?grant_type=client_credential&appid=” + appid + “&secret=” + secret

urls := []string{“api.weixin.qq.com”, “api2.weixin.qq.com”, “sh.api.weixin.qq.com”, “sz.api.weixin.qq.com”, “hk.api.weixin.qq.com”}

success := false
for _, v := range urls {
url := “https://“ + v + params
resp, err := http.Get(url)
if nil != err {
log.Println(“get wx access token from “+url+” error,err=”, err)
} else {
success = true
log.Println(“get wx access token from “ + url + “ success”)

defer resp.Body.Close()
body, err := ioutil.ReadAll(resp.Body)
if nil != err {
log.Println(“get wx access token error,read resp body error,err=”, err)
return
}
tokenstr := string(body)
log.Println(“access_token:”, tokenstr)
ParseTokens(tokenstr)
break
}
}

if !success {
log.Println(“get wx access error from all api”)
os.Exit(1)
}
}

func InitGlobal() {

wx_gzh_appid = “”
wx_gzh_secret = “”
wx_gzh_token_str = “”

global_access_token = “”
global_access_token_time_out = 0
}

func HttpTokenServer(tokenPort string) {
http.Handle(“/token”, &wx_access_token_center_handler{})
port := “0.0.0.0:” + tokenPort
log.Println(“start listen token port:”, tokenPort)
http.ListenAndServe(port, nil)
}

func main() {

log.Println(“start gzh token center”)
log.Println(“param format: config.json”)

arg_num := len(os.Args)

if arg_num < 2 {
log.Println(“please input the port”)
os.Exit(1)
}

InitGlobal()
configFile := os.Args[1]

config, err := ParseSconsConfig(configFile)

if nil != err {
log.Println(“parse config error,err=”, err)
os.Exit(1)
}
wx_gzh_appid = config.Appid
wx_gzh_secret = config.Secret
wx_gzh_token_str = config.Token

HttpTokenServer(config.Port)
}

1. 前言

编写过C语言程序的肯定知道通过malloc()方法动态申请内存，其中内存分配器使用的是glibc提供的ptmalloc2。 除了glibc，业界比较出名的内存分配器有Google的tcmalloc和Facebook的jemalloc。二者在避免内存碎片和性能上均比glic有比较大的优势，在多线程环境中效果更明显。 Golang中也实现了内存分配器，原理与tcmalloc类似，简单的说就是维护一块大的全局内存，每个线程(Golang中为P)维护一块小的私有内存，私有内存不足再从全局申请。 另外，内存分配与GC（垃圾回收）关系密切，所以了解GC前有必要了解内存分配的原理。

2. 基础概念

为了方便自主管理内存，做法便是先向系统申请一块内存，然后将内存切割成小块，通过一定的内存分配算法管理内存。 以64位系统为例，Golang程序启动时会向系统申请的内存如下图所示：

预申请的内存划分为spans、bitmap、arena三部分。其中arena即为所谓的堆区，应用中需要的内存从这里分配。其中spans和bitmap是为了管理arena区而存在的。 arena的大小为512G，为了方便管理把arena区域划分成一个个的page，每个page为8KB,一共有512GB/8KB个页； spans区域存放span的指针，每个指针对应一个page，所以span区域的大小为(512GB/8KB)*指针大小8byte = 512M bitmap区域大小也是通过arena计算出来，不过主要用于GC。

2.1 span

span是用于管理arena页的关键数据结构，每个span中包含1个或多个连续页，为了满足小对象分配，span中的一页会划分更小的粒度，而对于大对象比如超过页大小，则通过多页实现。

2.1.1 class

跟据对象大小，划分了一系列class，每个class都代表一个固定大小的对象，以及每个span的大小。如下表所示：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67

// class  bytes/obj  bytes/span  objects  waste bytes
//     1          8        8192     1024            0
//     2         16        8192      512            0
//     3         32        8192      256            0
//     4         48        8192      170           32
//     5         64        8192      128            0
//     6         80        8192      102           32
//     7         96        8192       85           32
//     8        112        8192       73           16
//     9        128        8192       64            0
//    10        144        8192       56          128
//    11        160        8192       51           32
//    12        176        8192       46           96
//    13        192        8192       42          128
//    14        208        8192       39           80
//    15        224        8192       36          128
//    16        240        8192       34           32
//    17        256        8192       32            0
//    18        288        8192       28          128
//    19        320        8192       25          192
//    20        352        8192       23           96
//    21        384        8192       21          128
//    22        416        8192       19          288
//    23        448        8192       18          128
//    24        480        8192       17           32
//    25        512        8192       16            0
//    26        576        8192       14          128
//    27        640        8192       12          512
//    28        704        8192       11          448
//    29        768        8192       10          512
//    30        896        8192        9          128
//    31       1024        8192        8            0
//    32       1152        8192        7          128
//    33       1280        8192        6          512
//    34       1408       16384       11          896
//    35       1536        8192        5          512
//    36       1792       16384        9          256
//    37       2048        8192        4            0
//    38       2304       16384        7          256
//    39       2688        8192        3          128
//    40       3072       24576        8            0
//    41       3200       16384        5          384
//    42       3456       24576        7          384
//    43       4096        8192        2            0
//    44       4864       24576        5          256
//    45       5376       16384        3          256
//    46       6144       24576        4            0
//    47       6528       32768        5          128
//    48       6784       40960        6          256
//    49       6912       49152        7          768
//    50       8192        8192        1            0
//    51       9472       57344        6          512
//    52       9728       49152        5          512
//    53      10240       40960        4            0
//    54      10880       32768        3          128
//    55      12288       24576        2            0
//    56      13568       40960        3          256
//    57      14336       57344        4            0
//    58      16384       16384        1            0
//    59      18432       73728        4            0
//    60      19072       57344        3          128
//    61      20480       40960        2            0
//    62      21760       65536        3          256
//    63      24576       24576        1            0
//    64      27264       81920        3          128
//    65      28672       57344        2            0
//    66      32768       32768        1            0

上表中每列含义如下：

• class： class ID，每个span结构中都有一个class ID, 表示该span可处理的对象类型
• bytes/obj：该class代表对象的字节数
• bytes/span：每个span占用堆的字节数，也即页数*页大小
• objects: 每个span可分配的对象个数，也即（bytes/spans）/（bytes/obj）
• waste bytes: 每个span产生的内存碎片，也即（bytes/spans）%（bytes/obj）

上表可见最大的对象是32K大小，超过32K大小的由特殊的class表示，该class ID为0，每个class只包含一个对象。

2.1.2 span数据结构

span是内存管理的基本单位,每个span用于管理特定的class对象, 跟据对象大小，span将一个或多个页拆分成多个块进行管理。 src/runtime/mheap.go:mspan定义了其数据结构：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

type mspan struct {
next *mspan//链表前向指针，用于将span链接起来
prev *mspan//链表前向指针，用于将span链接起来
startAddr uintptr // 起始地址，也即所管理页的地址
npages    uintptr // 管理的页数

nelems uintptr // 块个数，也即有多少个块可供分配

allocBits  *gcBits //分配位图，每一位代表一个块是否已分配

allocCount  uint16     // 已分配块的个数
spanclass   spanClass  // class表中的class ID

elemsize    uintptr    // class表中的对象大小，也即块大小
}

以class 10为例，span和管理的内存如下图所示：  spanclass为10，参照class表可得出npages=1,nelems=56,elemsize为144。其中startAddr是在span初始化时就指定了某个页的地址。allocBits指向一个位图，每位代表一个块是否被分配，本例中有两个块已经被分配，其allocCount也为2。 next和prev用于将多个span链接起来，这有利于管理多个span，接下来会进行说明。

2.2 cache

有了管理内存的基本单位span，还要有个数据结构来管理span，这个数据结构叫mcentral，各线程需要内存时从mcentral管理的span中申请内存，为了避免多线程申请内存时不断的加锁，Golang为每个线程分配了span的缓存，这个缓存即是cache。 src/runtime/mcache.go:mcache定义了cache的数据结构：

1
2
3

type mcache struct {
alloc [67*2]*mspan // 按class分组的mspan列表
}

alloc为mspan的指针数组，数组大小为class总数的2倍。数组中每个元素代表了一种class类型的span列表，每种class类型都有两组span列表，第一组列表中所表示的对象中包含了指针，第二组列表中所表示的对象不含有指针，这么做是为了提高GC扫描性能，对于不包含指针的span列表，没必要去扫描。 根据对象是否包含指针，将对象分为noscan和scan两类，其中noscan代表没有指针，而scan则代表有指针，需要GC进行扫描。 mcache和span的对应关系如下图所示：  mchache在初始化时是没有任何span的，在使用过程中会动态的从central中获取并缓存下来，跟据使用情况，每种class的span个数也不相同。上图所示，class 0的span数比class1的要多，说明本线程中分配的小对象要多一些。

2.3 central

cache作为线程的私有资源为单个线程服务，而central则是全局资源，为多个线程服务，当某个线程内存不足时会向central申请，当某个线程释放内存时又会回收进central。 src/runtime/mcentral.go:mcentral定义了central数据结构：

1
2
3
4
5
6
7
8

type mcentral struct {
lock      mutex     //互斥锁
spanclass spanClass // span class ID
nonempty  mSpanList // non-empty 指还有空闲块的span列表
empty     mSpanList // 指没有空闲块的span列表

nmalloc uint64      // 已累计分配的对象个数
}

• lock: 线程间互斥锁，防止多线程读写冲突
• spanclass : 每个mcentral管理着一组有相同class的span列表
• nonempty: 指还有内存可用的span列表
• empty: 指没有内存可用的span列表
• nmalloc: 指累计分配的对象个数

线程从central获取span步骤如下：

1. 加锁
2. 从nonempty列表获取一个可用span，并将其从链表中删除
3. 将取出的span放入empty链表
4. 将span返回给线程
5. 解锁
6. 线程将该span缓存进cache

线程将span归还步骤如下：

1. 加锁
2. 将span从empty列表删除
3. 将span加入noneempty列表
4. 解锁

上述线程从central中获取span和归还span只是简单流程，为简单起见，并未对具体细节展开。

2.4 heap

从mcentral数据结构可见，每个mcentral对象只管理特定的class规格的span。事实上每种class都会对应一个mcentral,这个mcentral的集合存放于mheap数据结构中。 src/runtime/mheap.go:mheap定义了heap的数据结构：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

type mheap struct {
lock      mutex

spans []*mspan

bitmap        uintptr //指向bitmap首地址，bitmap是从高地址向低地址增长的

arena_start uintptr//指示arena区首地址
arena_used  uintptr//指示arena区已使用地址位置

central [67*2]struct {
mcentral mcentral
pad      [sys.CacheLineSize - unsafe.Sizeof(mcentral{})%sys.CacheLineSize]byte
}
}

• lock： 互斥锁
• spans: 指向spans区域，用于映射span和page的关系
• bitmap：bitmap的起始地址
• arena_start: arena区域首地址
• arena_used: 当前arena已使用区域的最大地址
• central: 每种class对应的两个mcentral

从数据结构可见，mheap管理着全部的内存，事实上Golang就是通过一个mheap类型的全局变量进行内存管理的。 mheap内存管理示意图如下：  系统预分配的内存分为spans、bitmap、arean三个区域，通过mheap管理起来。接下来看内存分配过程。

3. 内存分配过程

针对待分配对象的大小不同有不同的分配逻辑：

• (0, 16B) 且不包含指针的对象： Tiny分配
• (0, 16B) 包含指针的对象：正常分配
• [16B, 32KB] : 正常分配
• (32KB, -) : 大对象分配 其中Tiny分配和大对象分配都属于内存管理的优化范畴，这里暂时仅关注一般的分配方法。

以申请size为n的内存为例，分配步骤如下：

1. 获取当前线程的私有缓存mcache
2. 跟据size计算出适合的class的ID
3. 从mcache的alloc[class]链表中查询可用的span
4. 如果mcache没有可用的span则从mcentral申请一个新的span加入mcache中
5. 如果mcentral中也没有可用的span则从mheap中申请一个新的span加入mcentral
6. 从该span中获取到空闲对象地址并返回

4. 总结

Golang内存分配是个相当复杂的过程，其中还掺杂了GC的处理，这里仅仅对其关键数据结构进行了说明，了解其原理而又不至于深陷实现细节。

1. Golang程序启动时申请一大块内存，并划分成spans、bitmap、arena区域
2. arena区域按页划分成一个个小块
3. span管理一个或多个页
4. mcentral管理多个span供线程申请使用
5. mcache作为线程私有资源，资源来源于mcentral

本文来自云栖社区合作伙伴“开源中国”

本文作者：达尔文

原文链接

1——Z 到 A（译注：倒序）

当你第一次学习 Go 的时候可能会中招。 例子

1
2
3
4
5

func main() {
  for i := 0; i < 4; i++ {
    defer fmt.Print(i)
  }
}

输出 Go 的运行时会将延迟执行的函数保存至一个栈中（译注：意味着它们会按照入栈的顺序倒序执行）。想了解更多，请阅读这篇 文章 GCTT 出品的译文：图解 Go 中的延迟调用 defer。

1
2
3
4

3
2
1
0

2——作用域屏蔽了参数

事实上这是一个作用域的坑，但我想要让你知道它与 defer 和 已命名的返回值 之间的关系。 例子 这里我们定义了一个函数，这个函数声明了它需要延迟的函数（在返回的时候释放资源 r ）。

接着创建一个 reader 类型的结构体使得调用 Close 的时候返回一个 error

1
2
3
4
5

type reader struct{}

func (r reader) Close() error {
  return errors.New("Close Error")
}

当 reader 调用 Close() 的时候总会返回一个 error ，release 会在 defer 内部调用。

1
2
3
4
5

r := reader{}

err := release(r)

fmt.Print(err)

输出

1

nil

变量 err 的值为 nil ，而我们期望中的值应该是 “Close Error” 。

为什么会这样？

延迟函数内的赋值语句在延迟函数的 if 块中，因此在块中的 err 变量赋值会创建一个全新的变量，块级变量 err 的作用域会屏蔽返回变量 err ，因此， release() 还是返回 err 的原始值。

解决方案

我们需要将值赋给 release() 的 err 变量，为了做到这一点，请看下面图示的第三行，这行代码并没有声明新的 err 变量，与之前不同的是，它使用的是原本的 err 返回变量（将 := 替换成 =）。这就解决了块级屏蔽的问题。 如果你对 = 和 := ，请看一下这篇 文章

3——参数很快得到了值

当一个 defer 函数出现而不是被执行的时候，传递给它的参数的值就会被立刻确定下来，在我的其他文章中有讲过类似的 例子 。 例子

1
2
3
4
5
6
7
8
9
10
11

type message struct {
  content string
}

func (p *message) set(c string) {
  p.content = c
}

func (p *message) print() string {
  return p.content
}

试着运行一下上面的代码

1
2
3
4
5
6
7
8
9

func() {
  m := &message{content: "Hello"}

  defer fmt.Print(m.print())

  m.set("World")

  // 被延迟的函数在这里执行
}

输出

1

"Hello"

为什么输出不是 “World” ?

在 defer 中， fmt.Print 被推迟到函数返回后执行，可是 m.print() 的值在当时就已经被求出，因此， m.print() 会返回 _”Hello”_，这个值会保存一直到外围函数返回。 这个过程类似于调用 fmt.Print() 打印 “Hello” ，进一步理解这个过程，可以看这篇 文章 。

4——循环中存址

当延迟函数执行的时候，会查看当时周围变量中的值 —— 除了被传入参数的值。我们来看看这一切是怎么在循环中发生的。 例子 我们在循环里定义了一个闭包函数。

1
2
3
4
5

for i := 0; i < 3; i++ {
  defer func() {
   fmt.Println(i)
  }()
}

输出

1
2
3

3
3
3

为什么？

当代码执行的时候，被延迟的函数会查看当时 i 的值，这是因为，当 defer 出现的时候， Go 的运行时会保存 i 的地址，在 for 循环结束之后 i 的值变成了 3。 因此，当延迟语句运行的时候，所有的延迟栈中的语句都会去查看 i 地址中的值，也就是 3 （被当做循环结束后的当时值）。 所有的延迟函数会查看相同的 i ，循环结束（值变成了3)，因此它们查看到的都是 3 。

解决方案

直接向延迟函数传参数。

1
2
3
4
5

for i := 0; i < 3; i++ {
  defer func(i int) {
   fmt.Println(i)
  }(i)
}

1
2
3

2
1
0

为什么这个又能正常执行？

因为，这时 Go 的运行时在 for 循环的作用域中又创建了不同的 i 变量并把正确的值也保存在了那些变量中，现在，延迟函数不会去查看原始循环中的 i 变量，它们会查看各自的局部 i 变量。

解决方案 #2

在这里，我们故意使用一个新的 i 块级变量来屏蔽循环中的 i ，说实话我不太喜欢这种风格，所以我把这种方式放到了 Hacker News 上供大家讨论。

1
2
3
4
5
6

for i := 0; i < 3; i++ {
  i := i
  defer func() {
    fmt.Println(i)
  }()
}

解决方案 #3

如果一次延迟调用一个函数，你可以直接对这个函数使用 defer 。

1
2
3

for i := 0; i < 3; i++ {
  defer fmt.Println(i)
}

5——不返回的意义

对于调用者来说，在延迟函数中返回值几乎没有什么影响，可是，你依然可以使用 命名返回值 来影响返回的结果。 例子

1
2
3
4
5
6
7

func release() error {
  defer func() error {
    return errors.New("error")
  }()

  return nil
}

输出

1

nil

解决方案

1
2
3
4
5
6
7

func release() (err error) {
  defer func() {
    err = errors.New("error")
  }()

  return nil
}

输出

1

"error"

为什么能起作用？

在这里，我们在 defer 中，对 函数的 err 返回变量赋了新的值，并且函数会返回那个值，defer 函数并不直接返回值，它影响了返回命名变量的这个过程。

小结

你不需要处处使用 defer ，没有 defer 你也可以直接返回 error 。 在函数有多个返回情况而你想要集中处理它们的时候使用 defer 会很方便，多思考如何进一步简化你的代码。

via: https://blog.learngoprogramming.com/5-gotchas-of-defer-in-go-golang-part-ii-cc550f6ad9aa 作者：Inanc Gumus  译者：yujiahaol68  校对：polaris1119 本文由 GCTT 原创编译，Go语言中文网 荣誉推出

本文只适合想要进阶学习 Golang 的新手阅读，大牛请绕道。

#1 – defer nil 函数

如果一个延迟函数被赋值为 nil ， 运行时的 panic 异常会发生在外围函数执行结束后而不是 defer 的函数被调用的时候。 例子

1
2
3
4
5
6

func() {
  var run func() = nil
  defer run()

  fmt.Println("runs")
}

输出结果

1
2
3

runs

❗️ panic: runtime error: invalid memory address or nil pointer dereference

发生了什么？

名为 func 的函数一直运行至结束，然后 defer 函数会被执行且会因为值为 nil 而产生 panic 异常。然而值得注意的是，run() 的声明是没有问题，因为在外围函数运行完成后它才会被调用。 上面只是一个简单的案例，但同样的案例也可能发生在真实世界中，所以如果你遇上的话，可以想想是不是掉进了这个坑里。

#2 – 在循环中使用 defer

切忌在循环中使用 defer，除非你清楚自己在做什么，因为它们的执行结果常常会出人意料。 但是，在某些情况下，在循环中使用 defer 会相当方便，例如将函数中的递归转交给 defer，但这显然已经不是本文应该讲解的内容。 在上面的例子中，defer row.Close() 在循环中的延迟函数会在函数结束过后运行，而不是每次 for 循环结束之后。这些延迟函数会不停地堆积到延迟调用栈中，最终可能会导致一些不可预知的问题。

解决方案 #1：

不使用 defer ，直接在末尾调用。

解决方案 #2:

将任务转交给另一个函数然后在里面使用 defer，在下面这种情况下，延迟函数会在每次匿名函数执行结束后执行。

进行基准测试

查看代码

#3 – 延迟调用含有闭包的函数

有时出于某种缘由，你想要让那些闭包延迟执行。例如，连接数据库，然后在查询语句执行过后中断与数据库的连接。 例子

1
2
3
4
5
6
7
8
9

type database struct{}

func (db *database) connect() (disconnect func()) {
  fmt.Println("connect")

  return func() {
    fmt.Println("disconnect")
  }
}

运行一下

1
2
3
4

db := &database{}
defer db.connect()

fmt.Println("query db...")

输出结果

1
2

query db...
connect

竟然出问题了？

最终 disconnect 并没有输出，最后只有 connect ，这是一个 bug，最终的情况是 connect() 执行结束后，其执行域得以被保存起来，但内部的闭包并不会被执行。

解决方案

1
2
3
4
5
6
7

func() {
  db := &database{}
  close := db.connect()
  defer close()

  fmt.Println("query db...")
}

稍作修改后， db.connect() 返回了一个函数，然后我们再对这个函数使用 defer 就能够在 func() 执行结束后断开与数据库的连接。 输出结果

1
2
3

connect
query db...
disconnect

糟糕的处理方式：

即便这种处理方式很糟，但我还是想告诉你如何不用变量来解决这个问题，因此，我希望你能以此来了解 defer 亦或是 go 语言的运行机制。

1
2
3
4
5
6

func() {
  db := &database{}
  defer db.connect()()

  ..
}

这段代码从技术层面上说与上面的解决方案没有本质区别。其中，第一个圆括号是连接数据库（在 defer db.connect() 中立即执行的部分），然后第二个圆括号是为了在 func() 结束时延迟执行断开连接的函数(也就是返回的闭包)。 归因于 db.connect() 创建了一个闭包类型的值，然后再使用 defer 声明闭包函数， db.connect() 的值需要被实现计算出来以便让 defer 知道需要延迟哪个函数，这与 defer 不直接相关但也可能帮助你解决一些问题。

#4 – 在执行块中使用 defer

你可能想要在执行块执行结束后执行在块内延迟调用的函数，但事实并非如此，它们只会在块所属的函数执行结束后才被执行，这种情况适用于所有的代码块除了上文的函数块例如，for，switch 等。 因为：延迟是相对于一个函数而非一个代码块 例子

1
2
3
4
5
6
7
8
9
10
11

func main() {
  {
    defer func() {
      fmt.Println("block: defer runs")
    }()

    fmt.Println("block: ends")
  }

  fmt.Println("main: ends")
}

输出结果

1
2
3

block: ends
main: ends
block: defer runs

上例的延迟函数只会在函数执行结束后运行，而不是紧接着它所在的块（花括号内包含 defer 调用的区域）后执行，就像代码中的演示的那样，你可以使用花括号创造单独的执行块。

另一个解决方案

如果你希望在另一个块中使用 defer ，可以使用匿名函数（正如在第二个坑中我们采用的解决方案）。

1
2
3
4
5
6
7
8
9
10
11

func main() {
  func() {
    defer func() {
      fmt.Println("func: defer runs")
    }()

    fmt.Println("func: ends")
  }()

  fmt.Println("main: ends")
}

#5 – 延迟方法的坑

同样，你也可以使用 defer 来延迟 方法 调用，但也可能出一些岔子。

没有使用指针作为接收者

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

type Car struct {
  model string
}

func (c Car) PrintModel() {
  fmt.Println(c.model)
}

func main() {
  c := Car{model: "DeLorean DMC-12"}

  defer c.PrintModel()

  c.model = "Chevrolet Impala"
}

输出结果

1

DeLorean DMC-12

使用指针对象作为接收者

1
2
3

func (c *Car) PrintModel() {
  fmt.Println(c.model)
}

输出结果

1

Chevrolet Impala

为什么会这样？

我们需要记住的是，当外围函数还没有返回的时候，Go 的运行时就会立刻将传递给延迟函数的参数保存起来。 因此，当一个以值作为接收者的方法被 defer 修饰时，接收者会在声明时被拷贝（在这个例子中那就是 Car 对象），此时任何对拷贝的修改都将不可见（例中的 Car.model ），因为，接收者也同时是输入的参数，当使用 defer 修饰时会立刻得出参数的值(也就是 “DeLorean DMC-12” )。 在另一种情况下，当被延迟调用时，接收者为指针对象，此时虽然会产生新的指针变量，但其指向的地址依然与上例中的 “c” 指针的地址相同。因此，任何修改都会完美地作用在同一个对象中。 以上就是本文的全部内容，我会在后续的文章中补充更多类似的坑 – 已经有至少 15 个易犯的 defer 错误榜上有名，如果你有任何想法，欢迎在下面留言。

via: https://blog.learngoprogramming.com/gotchas-of-defer-in-go-1-8d070894cb01 作者：Inanc Gumus  译者：yujiahaol68  校对：rxcai 本文由 GCTT 原创编译，Go语言中文网 荣誉推出

译注：全文总共有四篇，本文为同系列文章的第三篇

• 第一部分
• 第二部分

本文将侧重于讲解使用 defer 的一些技巧 如果你对 defer 的基本操作还没有清晰的认识，请先阅读这篇 文章 （GCTT 出品的译文 https://studygolang.com/articles/11907）。

#1 —— 在延迟调用函数的外部使用 recover

你总是应该在被延迟函数的内部调用 recover() ，当出现一个 panic 异常时，在 defer 外调用 recover() 将无法捕获这个异常，而且 recover() 的返回值会是 nil 。 例子

1
2
3
4

func do() {
    recover()
    panic("error")
}

输出 recover 并没有成功捕获异常。

1

panic: error

解决方案

在延迟调用的函数内部使用 recover() 就能够避免这个问题。

1
2
3
4
5
6
7
8

func do() {
    defer func() {
        r := recover()
        fmt.Println("recovered:", r)
    }()

    panic("error")
}

输出

1

recovered: error

#2 —— 在错误的位置使用 defer

这个陷阱来自于这篇 Go 的 50 个阴影。 例子 当 http.Get 失败时会抛出异常。

1
2
3
4
5
6
7
8
9
10
11

func do() error {
    res, err := http.Get("http://notexists")
    defer res.Body.Close()
    if err != nil {
        return err
    }

    // ..code...

    return nil
}

输出

1

panic: runtime error: invalid memory address or nil pointer dereference

发生了什么？

因为在这里我们并没有检查我们的请求是否成功执行，当它失败的时候，我们访问了 Body 中的空变量 res ，因此会抛出异常

解决方案

总是在一次成功的资源分配下面使用 defer ，对于这种情况来说意味着：当且仅当 http.Get 成功执行时才使用 defer

1
2
3
4
5
6
7
8
9
10
11
12
13
14

func do() error {
    res, err := http.Get("http://notexists")
    if res != nil {
        defer res.Body.Close()
    }

    if err != nil {
        return err
    }

    // ..code...

    return nil
}

在上述的代码中，当有错误的时候，err 会被返回，否则当整个函数返回的时候，会关闭 res.Body 。

旁注 1

在这里，你同样需要检查 resp 的值是否为 nil ，这是 http.Get 中的一个警告。通常情况下，出错的时候，返回的内容应为空并且错误会被返回，可当你获得的是一个重定向 error 时， resp 的值并不会为 nil ，但其又会将错误返回。上面的代码保证了无论如何 Body 都会被关闭，如果你没有打算使用其中的数据，那么你还需要丢弃已经接收的数据。更多 详情。

#3 —— 不检查错误

简单地将清理的逻辑委托给 defer 并不意味着资源的释放就万无一失了，你也可能会错失有用的报错信息，让一些潜在的问题石沉大海。

反面教材

在这里，f.Close() 可能会返回一个错误，可这个错误会被我们忽略掉

1
2
3
4
5
6
7
8
9
10
11

func do() error {
    f, err := os.Open("book.txt")
    if err != nil {
        return err
    }
    defer f.Close()

    // ..code...

    return nil
}

改进一下

最好还是检查可能的错误而不是直接交给 defer 就完事，你可以把 defer 内的代码写成一个帮助函数来简化我们的代码，这里为了讲解方便就没有进行简化。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

func do() error {
    f, err := os.Open("book.txt")
    if err != nil {
        return err
    }

    defer func() {
        if err := f.Close(); err != nil {
            // log etc
        }
    }()

    // ..code...

    return nil
}

再改进一下

你也可以通过命名的返回变量来返回 defer 内的错误。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

func do() (err error) {
    f, err := os.Open("book.txt")
    if err != nil {
        return err
    }

    defer func() {
        if ferr := f.Close(); ferr != nil {
            err = ferr
        }
    }()

    // ..code...

    return nil
}

旁注 2

你可以使用这个 包 来整合多个不同的错误，这会非常必要因为 defer 中的 f.Close 可能会把之前的错误也覆盖掉，将多个错误包裹在一起能够将所有的错误信息都写入日志，在诊断问题的时候能有更多的依据。 你也可以使用这个 包 来查看你遗漏的本应该检查错误的地方。

#4 —— 释放相同的资源

在第三小节中有一个小小的警告：如果你尝试使用相同的变量释放不同的资源，那么这个操作可能无法正常执行。 例子 这段看似没什么问题的代码尝试第二次关闭相同的资源。第二个 变量 f 会被关闭两次，因为 f 变量 会因第二个资源而改变它的值

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

func do() error {
    f, err := os.Open("book.txt")
    if err != nil {
        return err
    }

    defer func() {
        if err := f.Close(); err != nil {
            // log etc
        }
    }()

    // ..code...

    f, err = os.Open("another-book.txt")
    if err != nil {
        return err
    }

    defer func() {
        if err := f.Close(); err != nil {
            // log etc
        }
    }()

    return nil
}

输出

1
2

closing resource #another-book.txt
closing resource #another-book.txt

发生了什么

正如我们所看到的，当延迟函数执行时，只有最后一个变量会被用到，因此，f 变量 会成为最后那个资源 (another-book.txt)。而且两个 defer 都会将这个资源作为最后的资源来关闭

解决方案

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

func do() error {
    f, err := os.Open("book.txt")
    if err != nil {
        return err
    }

    defer func(f io.Closer) {
        if err := f.Close(); err != nil {
            // log etc
        }
    }(f)

    // ..code...

    f, err = os.Open("another-book.txt")
    if err != nil {
        return err
    }

    defer func(f io.Closer) {
        if err := f.Close(); err != nil {
            // log etc
        }
    }(f)

    return nil
}

输出

1
2

closing resource #another-book.txt
closing resource #book.txt

你也可以使用函数来避免上述问题的发生，参考我在 这里 讲过的开闭模式。

#5 —— panic/recover 会取得并返回任意类型

你可能认为你总是需要往 panic 中传 string 或 error 类型的数据

传入 string

1
2
3
4
5
6
7
8
9

func errorly() {
    defer func() {
        fmt.Println(recover())
    }()

    if badHappened {
        panic("error run run")
    }
}

输出

1

"error run run"

传入 error

1
2
3
4
5
6
7
8
9

func errorly() {
    defer func() {
        fmt.Println(recover())
    }()

    if badHappened {
        panic(errors.New("error run run")
    }
}

输出

1

"error run run"

传入任意类型

正如你所看到的 panic 可以接收 string 以及 error类型 。这意味着事实上你可以给 panic 传 “任意类型” 的数据并能够在 defer 中使用 recover 来获取这个数据。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

type myerror struct {}

func (myerror) String() string {
    return "myerror there!"
}

func errorly() {
    defer func() {
        fmt.Println(recover())
    }()

    if badHappened {
        panic(myerror{})
    }
}

为什么可以这么写？

这是因为 panic 的函数签名显示它可以接收 interface{} 类型，我们可以将它理解为 Go 中的 “任意类型” 这是 panic 的签名

1

func panic(v interface{})

recover 的签名

1

func recover() interface{}

因此，基本上它会这样运行

1

panic(value) -> recover() -> value

recover 会把传入 panic 的值返回出来 这一部分就先告一段落了，我们第四部分见！

via: https://blog.learngoprogramming.com/5-gotchas-of-defer-in-go-golang-part-iii-36a1ab3d6ef1 作者：Inanc Gumus  译者：yujiahaol68  校对：polaris1119 本文由 GCTT 原创编译，Go语言中文网 荣誉推出

从新历年开始，就想着要写写2018的总结。 几次想下笔写，想了想又没有下笔，有些事做起来确实很mo，老婆说的。、 虽然有点mo，但是一般决定了的事情还是会去做，就是比自己预想的时间要晚一点，嗯，这个是遗传的，老爸也是这个样子。希望我的娃尽量不要遗传了这个坏习惯。 先说说工作上的事吧。 2018，还是继续呆在游爱，游爱怎么说呢，在工作和生活之间，能够比较好地找到一个平衡，当时选择游爱，这也是一个非常重要的原因。毕竟要考虑结婚啦。但是所在的项目确实不咋地，作为一个老项目，虽然极度敬佩这个项目的生命力，7年，讲道理，很多端游都不一定有这么长的生命周期，而且还能赚不少钱。原因我个人觉得可能是拥有一批忠实的老玩家，还有就是在三国SLG这个领域，风云这个品牌经营的很好。 还有就是和杨永他们搞搞其他的，看看是不是要有些额外的想法，周末有空的时候搞搞自己的项目。 生活上，当然就是亲爱的怀孕啦，然后把结婚的日子提前，把婚礼给办了。 结婚前感觉好多东西都还没准备好，没办法啦，小宝贝提前来了，一切以宝宝为优先啦。 再然后就是按计划把车给买啦，最开始考虑要不要先买房，但是后来想想，现在这个经济大环境，加上我自己有些其他的想法，还是决定先不买房了，先买个车吧，买房的事，还是等30岁再考虑吧。 2019的3.13号下午17:40，宝宝37+2周，足月出来，成功升级，总感觉我娃贼帅，哈哈，继承了他老爸我年轻时候的模样。带娃就是他醒了你就要围着他来转，他睡着之后你还要收拾好各种东西，才能跟着稍微睡一睡，虽然很累，但是幸福呐。 3月还有就是外婆走了，90岁了，这两年身体也不好，刚好我在休陪产假，本来打算是一回家就去探望下的，顺便告诉他，我娃出生了，但是当时老妈说外婆生病了，回来又要照顾娃，娃又没满月，就不让我去，我就打算等我出广州那天再去探望下，没想到那两天气温突然下降了很多，可能就是这样吧，外婆没能撑过去，我也没能告诉她，有些时候，真的是不知道明天和意外，哪个会先来，我们能做的，只有活在当下。 2018，整体是不错的一年，自己给自己定的一些小目标，有些做到了，有些没做到，2019，继续自勉吧。 ——-ps，今晚暴兵项目要部署正是外网，各种问题，刚好又几个参数模块我负责的，要留下来加班。头疼，已经12点半了。 不过还好，就快弄好了，虽然写的很水，但是总算是把2018总结这个待办事项处理掉了，准备再看看项目部署还有没有问题，没问题就回去洗洗睡了。 —————2019-04-09   00:40    来自广州天河岗顶龙泽大厦20楼。