标签 goroutine 下的文章

理解unsafe-assume-no-moving-gc包

本文永久链接 – https://tonybai.com/2023/04/16/understanding-unsafe-assume-no-moving-gc

1. 背景

在之前的《Go与神经网络:张量计算》一文中,不知道大家是否发现了,所有例子代码执行时,前面都加了一个环境变量ASSUME_NO_MOVING_GC_UNSAFE_RISK_IT_WITH,就像下面这样:

$ASSUME_NO_MOVING_GC_UNSAFE_RISK_IT_WITH=go1.20 go run tensor.go

这是怎么回事儿呢?如果不加上这个环境变量会发生什么呢?我们来试试:

// https://github.com/bigwhite/experiments/blob/master/go-and-nn/tensor-operations/tensor.go

$go run tensor.go
panic: Something in this program imports go4.org/unsafe/assume-no-moving-gc to declare that it assumes a non-moving garbage collector, but your version of go4.org/unsafe/assume-no-moving-gc hasn't been updated to assert that it's safe against the go1.20 runtime. If you want to risk it, run with environment variable ASSUME_NO_MOVING_GC_UNSAFE_RISK_IT_WITH=go1.20 set. Notably, if go1.20 adds a moving garbage collector, this program is unsafe to use.

goroutine 1 [running]:
go4.org/unsafe/assume-no-moving-gc.init.0()
    /Users/tonybai/Go/pkg/mod/go4.org/unsafe/assume-no-moving-gc@v0.0.0-20220617031537-928513b29760/untested.go:25 +0x1ba
exit status 2

我们看到,程序panic了!我们看到panic的错误信息提到了go4.org/unsafe/assume-no-moving-gc这个包,显然是这个包在“作祟”,那么assume-no-moving-gc这个包究竟是做什么的呢?究竟有何功用?为何gorgonia.org/tensor会依赖这个包?这超出了《Go与神经网络:张量计算》那篇文章的范畴,所以我并未提及。在这篇文章中,我就和大家一起来理解一下unsafe-assume-no-moving-gc这个包。

2. unsafe-assume-no-moving-gc究竟是什么包?

unsafe-assume-no-moving-gc这个包的canonical import path是go4.org/unsafe/assume-no-moving-gc,显然它是go4.org这个组织开源的包。我们看看go4.org的主页(如下图):

这个站点主页非常“简陋”,最大的价值在于解释了go4的来历:gopher的谐音。go4.org开源了一些Go包,这个在其官方github站点可以看到:

项目不多,Star数也不多,但随便翻看一个项目的contributor,我们能看到前Googler、前Go核心团队成员、net/http包的设计者Brad Fitzpatrick(bradfitz)以及Go runtime的核心贡献者Josh Bleecher Snyder(josharian)。现在这两人似乎都在初创公司tailscale任职,做基于wireguard协议的远程安全控制平台(简单理解就是VPN平台)。tailscale汇集了一撮Go语言的原核心开发,go4.org就是他们开源的一些misc go包。而unsafe-assume-no-moving-gc这个包就是其中之一。

那么这个包究竟是做什么的呢?我们接着往下看。

3. unsafe-assume-no-moving-gc的工作原理

unsafe-assume-no-moving-gc是一个非常简单的包:

$tree unsafe-assume-no-moving-gc -F
unsafe-assume-no-moving-gc
├── LICENSE
├── README.md
├── assume-no-moving-gc.go
├── assume-no-moving-gc_test.go
├── go.mod
└── untested.go

0 directories, 6 files

除了test源文件外,它的源文件只有两个assume-no-moving-gc.go和untested.go。打开这两个源文件,你会发现这个包甚至都没有提供任何API。那这个包究竟是做什么用的呢?下面是这个包的README:

大致的理解就是如果你的代码中使用了Go中的unsafe tip,那么你的程序可以正常工作的前提是Go运行时垃圾回收器不是一个带迁移机制的回收器(collector)

所谓带迁移机制的collector,即在GC回收时可能将某些heap object挪到其他内存地址上。你的程序如果导入unsafe-assume-no-moving-gc这个包,就可以在Go GC支持迁移机制时以“程序启动崩溃”的行为提醒你。

我们来看一个例子:

// main.go
package main

import (
    "fmt"

    _ "go4.org/unsafe/assume-no-moving-gc"
)

func main() {
    fmt.Println("unsafe-assume-no-moving-gc demo")
}

go mod tidy后,使用Go 1.20版本运行该源文件:

$go mod tidy
go: finding module for package go4.org/unsafe/assume-no-moving-gc
go: downloading go4.org/unsafe/assume-no-moving-gc v0.0.0-20230221090011-e4bae7ad2296
go: downloading go4.org v0.0.0-20230225012048-214862532bf5

$go run main.go
unsafe-assume-no-moving-gc demo

由于目前最新Go 1.20.x版本的GC并非带迁移机制的GC,因此使用Go 1.20跑上面程序不会导致panic。

我们将unsafe-assume-no-moving-gc包回退到以前的版本,比如:v0.0.0-20230221090011-e4bae7ad2296,然后再run一遍main.go:

$go get go4.org/unsafe/assume-no-moving-gc@v0.0.0-20201222180813-1025295fd063
go: downgraded go4.org/unsafe/assume-no-moving-gc v0.0.0-20230221090011-e4bae7ad2296 => v0.0.0-20201222180813-1025295fd063

$go run main.go
panic: Something in this program imports go4.org/unsafe/assume-no-moving-gc to declare that it assumes a non-moving garbage collector, but your version of go4.org/unsafe/assume-no-moving-gc hasn't been updated to assert that it's safe against the go1.20 runtime. If you want to risk it, run with environment variable ASSUME_NO_MOVING_GC_UNSAFE_RISK_IT_WITH=go1.20 set. Notably, if go1.20 adds a moving garbage collector, this program is unsafe to use.

goroutine 1 [running]:
go4.org/unsafe/assume-no-moving-gc.init.0()
    /Users/tonybai/Go/pkg/mod/go4.org/unsafe/assume-no-moving-gc@v0.0.0-20201222180813-1025295fd063/untested.go:24 +0x1ba
exit status 2

从输出的panic error信息中,我们看到go4.org/unsafe/assume-no-moving-gc尚未被升级到可以信任go 1.20版本的版本,因此以Go 1.20运行该程序可能有风险。如果你能确认不会存在问题,可以用ASSUME_NO_MOVING_GC_UNSAFE_RISK_IT_WITH=go1.20这个环境变量来避免panic,比如下面这个输出:

$ASSUME_NO_MOVING_GC_UNSAFE_RISK_IT_WITH=go1.20 go run main.go
unsafe-assume-no-moving-gc demo

那么unsafe-assume-no-moving-gc包是怎么做到上述“检测”的呢?其诀窍就在untested.go这个源文件中。我们下载go4.org/unsafe/assume-no-moving-gc源码,并将其“回退”到1025295fd063这个commit时刻:

$git checkout 1025295fd063
Note: checking out '1025295fd063'.

... ...

HEAD is now at 1025295 flesh out package doc

查看untested.go:

// Copyright 2020 Brad Fitzpatrick. All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.

// +build go1.18

package assume_no_moving_gc

import (
    "os"
    "runtime"
    "strings"
)

func init() {
    dots := strings.SplitN(runtime.Version(), ".", 3)
    v := runtime.Version()
    if len(dots) >= 2 {
        v = dots[0] + "." + dots[1]
    }
    if os.Getenv(env) == v {
        return
    }
    panic("Something in this program imports go4.org/unsafe/assume-no-moving-gc to declare that it assumes a non-moving garbage collector, but your version of go4.org/unsafe/assume-no-moving-gc hasn't been updated to assert that it's safe against the " + v + " runtime. If you want to risk it, run with environment variable " + env + "=" + v + " set. Notably, if " + v + " adds a moving garbage collector, this program is unsafe to use.")
}

这个文件有两个特点:

  • 使用了build constraint:// +build go1.18,这意味着在你使用Go 1.18及更高版本时,该源文件才会参与编译。
  • 包含了init函数,你的代码在导入assume_no_moving_gc包时,该init函数会执行,产生“副作用”。

注:关于build constraint的用法,参见go help buildconstraint。

这样,我们使用go 1.20版本运行上面main.go时,由于go 1.20版本大于go 1.18版本,untested.go将被编译且其中的init函数将被执行,如果env这个常量(“ASSUME_NO_MOVING_GC_UNSAFE_RISK_IT_WITH”)所对应的环境变量没有设置,那么init函数将走到panic,从而导致程序退出并输出panic信息。

现在我们将assume_no_moving_gc包的版本切换回最新版本,最新版本的untested.go中的build constraint如下:

  //go:build go1.21
  // +build go1.21

这意味着你使用Go 1.21或以上版本时,untested.go文件才会被编译,如果我们使用go 1.20版本运行main.go,我们便不会“触发”untested.go中init函数的副作用,于是main.go得以正常运行。

注:截至go 1.20版本,Go GC依然不会挪动heap object。

在理解unsafe-assume-no-moving-gc包之前,我就该包的功用“咨询”了ChatGPT,ChatGPT的回答如下:

可以看出,ChatGPT基本上是一本正经地“胡说八道”。

4. 小结

unsafe-assume-no-moving-gc只针对GC对heap object的迁移,而不会保证栈地址的迁移,我们知道,Go中栈地址是会变的,因为goroutine的初始栈才2KB,一旦超出这个范围,Go runtime就会对栈进行扩展,即分配一个更大的地址范围作为goroutine的栈,然后将原栈上的变量迁移到新栈中,这样原先栈上变量的地址就都会发生变化。

不过,如果你的Go源码中采用了unsafe tips,依赖了heap object的地址,那么这里建议你导入unsafe-assume-no-moving-gc包。但要注意,随着go最新版本的发布,你要及时更新依赖的unsafe-assume-no-moving-gc的版本。否则当用户使用最新版本go时,依赖你的包的程序就会以panic来提醒。


“Gopher部落”知识星球旨在打造一个精品Go学习和进阶社群!高品质首发Go技术文章,“三天”首发阅读权,每年两期Go语言发展现状分析,每天提前1小时阅读到新鲜的Gopher日报,网课、技术专栏、图书内容前瞻,六小时内必答保证等满足你关于Go语言生态的所有需求!2023年,Gopher部落将进一步聚焦于如何编写雅、地道、可读、可测试的Go代码,关注代码质量并深入理解Go核心技术,并继续加强与星友的互动。欢迎大家加入!

img{512x368}
img{512x368}

img{512x368}
img{512x368}

著名云主机服务厂商DigitalOcean发布最新的主机计划,入门级Droplet配置升级为:1 core CPU、1G内存、25G高速SSD,价格5$/月。有使用DigitalOcean需求的朋友,可以打开这个链接地址:https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻)归档仓库 – https://github.com/bigwhite/gopherdaily

我的联系方式:

  • 微博(暂不可用):https://weibo.com/bigwhite20xx
  • 微博2:https://weibo.com/u/6484441286
  • 博客:tonybai.com
  • github: https://github.com/bigwhite

商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

聊聊Go语言的全局变量

本文永久链接 – https://tonybai.com/2023/03/22/global-variable-in-go

注:上面篇首配图的底图由百度文心一格生成。

C语言是Go语言的先祖之一,Go继承了很多C语言的语法与表达方式,这其中就包含了全局变量,虽然Go在其语法规范中并没有直接给出全局变量的定义。但是已经入门Go的童鞋都知道,在Go中包的导出变量(exported variable)起到的就是全局变量的作用。Go包导出变量与C的全局变量在优缺点与使用方式也有相似之处。

我是C程序员出身,对全局变量并不陌生,因此学习Go语言全局变量时,也没有太多Gap。不过来自其他语言(比如Java)的童鞋在学习Go全局变量时可能会觉得别扭,在全局变量的使用方式的理解方面也久久不能到位。

在这一篇中,我们就来聊聊Go语言的全局变量,和大家一起系统地理解一下。

一. Go中的全局变量

全局变量是一个可以在整个程序中被访问和修改的变量,不管它在哪里被定义。不同的编程语言有着不同的声明和使用全局变量的方式。

在Python中,你可以在module的任何地方声明一个全局变量。就像下面示例中的globvar。但是如果你想给它重新赋值,则需要在函数中使用global关键字。

globvar = 0

def set_globvar_to_one():
  global globvar # 要给全局变量globvar赋值
  globvar = 1

def print_globvar():
  print(globvar) # 读取全局变量globvar时无需global关键字

set_globvar_to_one()
print_globvar() # 打印1

Java中没有全局变量的概念,但你却可以使用一个类的public静态变量来模拟全局变量的作用,因为这样的public类静态变量可以被任何其他类在任何地方访问到。比如下面Java代码中globalVar:

public class GlobalExample {

  // 全局变量
  public static int globalVar = 10;

  // 全局常量
  public static final String GLOBAL_CONST = "Hello";

}

在Go中,全局变量指的是在包的最顶层声明的头母大写的导出变量,这样这个变量在整个Go程序的任何角落都可以被访问和修改,比如下面示例代码中foo包的变量Global:

package foo

var Global = "myvalue" // Go全局变量

package bar

import "foo"

func F1() {
    println(foo.Global)
    foo.Global = "another value"
}

foo.Global可以被任何导入foo包的其他包所读取和修改,就像上面代码F1中对它的那些操作。

即便是全局变量,按Go语法规范,上述Global变量的作用域也是package block的,而非universe block的,关于Go标识符的作用域,Go语言第一课专栏第11讲有系统详细地说明。

Go导出变量在Go中既然充当着全局变量的角色,它也就有了和其他语言全局变量一样的优劣势。接下来我们就来看看全局变量的优点与不足。

二. 全局变量的优缺点

俗话说:既然存在就有存在的“道理”!我们不去探讨“存在即合理”在哲学层面是否正确,我们先来看看全局变量的存在究竟能带来哪些好处。

1. 全局变量的优点

  • 首先,全局变量易于访问

全局变量的定义决定了它可以在程序的任何地方被访问。无论是在函数、方法、循环体内、深度缩进的条件语句块内部,全局变量都可以被直接访问到。这为减少函数参数个数带来一定“便利”,同时也省去了确定参数类型、实施参数传递的“烦恼”。

破壁人:全局变量容易被意外修改或被局部变量遮蔽,从而导致意想不到的问题。

  • 其次,全局变量易于共享数据

由于易于访问的特性,全局变量常用于在程序的不同部分之间共享数据,比如配置项数据、命令行标志(cmd flag)等。又由于全局变量的生命周期与程序的整个生命周期等同,不会因为函数调用结束而销毁,也不会被GC掉,可以始终存在并保持其值。因此全局变量被用作共享数据时,开发人员也不会有担心全局变量所在内存“已被回收”的心智负担。

破壁人: 并发的多线程或多协程(包括goroutine)访问同一个全局变量时需要考虑“数据竞争”问题。

  • 最后,全局变量让代码显得更为简洁

Go全局变量只需要在包的顶层声明一次即可,之后便可以在程序的任何地方对其进行访问和修改。对于声明全局变量的包的维护者而言,这样的代码再简洁不过了!

破壁人: 多处访问和修改全局变量的代码都与全局变量产生了直接的数据耦合,降低了可维护性和扩展性。

在上面的说明中,我针对全局变量的每条优点都写了一条“破壁人”观点,把这些破壁观点聚拢起来,就构成了全局变量的缺点集合,我们继续来看一下。

2. 全局变量的缺点

  • 首先,全局变量容易被意外修改或被局部变量遮蔽

前面提到,全局变量易于访问,这意味着所有地方都可能会直接访问或修改全局变量。任何一个位置改变了全局变量,都可能会以意想不到的方式影响着另外一个使用它的函数。这将导致针对这些函数的测试更为困难,全局变量的存在让各个测试之间隔离性不好,测试用例执行过程中如果修改了全局变量,测试执行结束前可能都需要将全局变量恢复到之前的状态,以尽可能保证对其他测试用例的干扰最小,下面是一个示例:

var globalVar int

func F1() {
    globalVar = 5
}

func F2() {
    globalVar = 6
}

func TestF1(t *testing) {
    old := globalVar
    F1()
    // assert the result
    ... ...
    globalVar = old // 恢复globalVar
}

func TestF2(t *testing) {
    old := globalVar
    F2()
    // assert the result
    ... ...
    globalVar = old // 恢复globalVar
}

此外,全局变量十分容易被函数、方法、循环体的同名局部变量所遮蔽(shadow),导致一些奇怪难debug的问题,尤其是与Go的短变量声明语法结合使用时

go vet支持对代码的静态分析,不过变量遮蔽检查的功能需要额外安装:

$go install golang.org/x/tools/go/analysis/passes/shadow/cmd/shadow@latest
$go vet -vettool=$(which shadow)
  • 其次,并发条件下,对全局变量的访问存在“数据竞争”问题

如果你的程序存在多个goroutine对全局变量的并发读写,那么“数据竞争”问题便不可避免。你需要使用额外的同步手段对全局变量进行保护,比如互斥锁、读写锁、原子操作等。

同理,没有同步手段保护的全局变量也限制了单元测试的并行执行能力(-paralell)。

  • 最后,全局变量在带来代码简洁性的同时,更多带来的是对扩展和复用不利的耦合性

全局变量让程序中所有访问和修改它的代码对其产生了数据耦合,全局变量的细微变化都将对这些代码产生影响。这样,如果要复用或扩展这些依赖全局变量的代码将变得十分困难。比如:若要对它们进行并行化执行,需要考虑其耦合的全局变量是否支持同步手段。若要复用其中的代码逻辑到其他程序中,可能还需要在新程序中创建一个新的全局变量。

我们看到,Go全局变量有优点,更有一堆不足,那么我们在实际生产编码过程中到底该如何对待全局变量呢?我们继续往下看。

三. Go全局变量的使用惯例与替代方案

到底Go语言是如何对待全局变量的?我翻了翻标准库来看看Go官方团队是如何对待全局变量的,我得到的结论是尽量少用

Go标准库中的全局变量用了“不少”,但绝大多数都是全局的“哨兵”错误变量,比如:

// $GOROOT/src/io/io.go
var ErrShortWrite = errors.New("short write")

// ErrShortBuffer means that a read required a longer buffer than was provided.
var ErrShortBuffer = errors.New("short buffer")

// EOF is the error returned by Read when no more input is available.
// (Read must return EOF itself, not an error wrapping EOF,
// because callers will test for EOF using ==.)
// Functions should return EOF only to signal a graceful end of input.
// If the EOF occurs unexpectedly in a structured data stream,
// the appropriate error is either ErrUnexpectedEOF or some other error
// giving more detail.
var EOF = errors.New("EOF")

// ErrUnexpectedEOF means that EOF was encountered in the
// middle of reading a fixed-size block or data structure.
var ErrUnexpectedEOF = errors.New("unexpected EOF")
... ...

关于错误处理中的“哨兵”错误处理模式,可以参考我的Go语言第一课专栏。更多Go错误处理模式在专栏中有系统讲解。

这些ErrXXX全局变量虽说是被定义为了“变量(Var)”,但Go开源许久以来,大家已经达成默契:这些ErrXXX变量仅是“只读”的,没人会对其进行任何修改操作。到这里有初学者可能会问:那为什么不将它们定义为常量呢?那是因为Go语言对常量的类型是有要求的:

Go常量有布尔常量、rune常量、整数常量、浮点常量、复数常量和字符串常量。

其他类型均不能被定义为常量。而errors.New返回的动态类型为errors.errorString结构体类型的指针,显然也不在常量类型范围之内。

除了ErrXXX这类全局变量外,Go标准库中其他全局变量就很少了。一个典型的全局变量是http.DefaultServeMux:

// $GOROOT/src/net/http/server.go

// DefaultServeMux is the default ServeMux used by Serve.
var DefaultServeMux = &defaultServeMux

var defaultServeMux ServeMux

// NewServeMux allocates and returns a new ServeMux.
func NewServeMux() *ServeMux { return new(ServeMux) }

http包是Go早期就携带的高频使用的包,我猜早期实现时出于某种原因定义了全局变量DefaultServeMux,后期可能由于兼容性原因保留了该全局变量,但从代码逻辑来看,去掉也不会有任何影响。

通过http包的DefaultServeMux、defaultServeMux和NewServeMux等逻辑,我们也可以看出Go语言采用的替代全局变量的方案,那就是“封装”。以http.ServeMux为例(我们假设删除掉DefaultServeMux这个全局变量,用包级非导出变量defaultServeMux替代它)。

http包定义了ServeMux类型以及相应方法用于处理HTTP请求的多路复用,但http包并未直接定义一个ServerMux的全局变量(我们假设删除了DefaultServeMux变量),而是定义了一个包级非导出变量defaultServeMux作为默认的Mux。

http包仅导出两个函数Handle和HandleFunc供调用者注册http请求路径与对应的handler(下面代码中的DefaultServeMux可换成defaultServeMux):

// $GOROOT/src/net/http/server.go

// Handle registers the handler for the given pattern
// in the DefaultServeMux.
// The documentation for ServeMux explains how patterns are matched.
func Handle(pattern string, handler Handler) { DefaultServeMux.Handle(pattern, handler) }

// HandleFunc registers the handler function for the given pattern
// in the DefaultServeMux.
// The documentation for ServeMux explains how patterns are matched.
func HandleFunc(pattern string, handler func(ResponseWriter, *Request)) {
    DefaultServeMux.HandleFunc(pattern, handler)
}

这样http完全不需要暴露Mux实现的细节,调用者也无需依赖一个全局变量,这个方案将原先的对全局变量的数据耦合转换为对http包的行为耦合。

类似的作法我们在标准库log包中也能看到,log包定义了包级变量std用作默认的Logger,但对外仅暴露Printf等系列打印函数,这些函数的实现会使用包级变量std的相应方法:

// $GOROOT/src/log/log.go

// Print calls Output to print to the standard logger.
// Arguments are handled in the manner of fmt.Print.
func Print(v ...any) {
    if std.isDiscard.Load() {
        return
    }
    std.Output(2, fmt.Sprint(v...))
}

// Printf calls Output to print to the standard logger.
// Arguments are handled in the manner of fmt.Printf.
func Printf(format string, v ...any) {
    if std.isDiscard.Load() {
        return
    }
    std.Output(2, fmt.Sprintf(format, v...))
}

// Println calls Output to print to the standard logger.
// Arguments are handled in the manner of fmt.Println.
func Println(v ...any) {
    if std.isDiscard.Load() {
        return
    }
    std.Output(2, fmt.Sprintln(v...))
}
... ...

注:其他语言可能有一些其他的替代全局变量的方案,比如Java的依赖注入。

四. 小结

综上,全局变量虽然有易于访问、易于共享、代码简洁等优点,但相较于其带来的意外修改、并发数据竞争、更高的耦合性等弊端而言,Go开发者选择了“尽量少用全局变量”的最佳实践。

此外,在Go中最常见的替代全局变量的方案就是封装,这个大家可以通过阅读标准库的典型源码慢慢体会。

注:本文部分内容来自于New Bing的Chat功能(据说是基于GPT-4大语言模型)生成的答案。


“Gopher部落”知识星球旨在打造一个精品Go学习和进阶社群!高品质首发Go技术文章,“三天”首发阅读权,每年两期Go语言发展现状分析,每天提前1小时阅读到新鲜的Gopher日报,网课、技术专栏、图书内容前瞻,六小时内必答保证等满足你关于Go语言生态的所有需求!2023年,Gopher部落将进一步聚焦于如何编写雅、地道、可读、可测试的Go代码,关注代码质量并深入理解Go核心技术,并继续加强与星友的互动。欢迎大家加入!

img{512x368}
img{512x368}

img{512x368}
img{512x368}

著名云主机服务厂商DigitalOcean发布最新的主机计划,入门级Droplet配置升级为:1 core CPU、1G内存、25G高速SSD,价格5$/月。有使用DigitalOcean需求的朋友,可以打开这个链接地址:https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻)归档仓库 – https://github.com/bigwhite/gopherdaily

我的联系方式:

  • 微博(暂不可用):https://weibo.com/bigwhite20xx
  • 微博2:https://weibo.com/u/6484441286
  • 博客:tonybai.com
  • github: https://github.com/bigwhite

商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

如发现本站页面被黑,比如:挂载广告、挖矿等恶意代码,请朋友们及时联系我。十分感谢! Go语言第一课 Go语言精进之路1 Go语言精进之路2 商务合作请联系bigwhite.cn AT aliyun.com

欢迎使用邮件订阅我的博客

输入邮箱订阅本站,只要有新文章发布,就会第一时间发送邮件通知你哦!

这里是 Tony Bai的个人Blog,欢迎访问、订阅和留言! 订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠 ,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过微信捐赠,请用微信客户端扫描下方赞赏码:

如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:

以太币:

如果您喜欢通过微信浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:
本站Powered by Digital Ocean VPS。
选择Digital Ocean VPS主机,即可获得10美元现金充值,可 免费使用两个月哟! 著名主机提供商Linode 10$优惠码:linode10,在 这里注册即可免费获 得。阿里云推荐码: 1WFZ0V立享9折!


View Tony Bai's profile on LinkedIn
DigitalOcean Referral Badge

文章

评论

  • 正在加载...

分类

标签

归档



View My Stats