先看一个结构体

// 写法一
type T1 struct {
	a int8
	b int64
	c int16
}

// 写法二
type T2 struct {
	a int8
	c int16
	b int64
}

对于这两个结构体，都有a、b、c三个定义完全一样的字段，只是在定义结构体的时候字段顺序不一样而已，那么两种写法有什么影响吗？

对于新手来说，感觉着没有什么区别的，只是一个书写顺序不同而已，但对于go编译器来说，则有着很大的区别，特别是在不同架构上(32位/64位）的编译器，在一定程度上对内存的使用大小和执行效率有着一定的不同。这里的主要知识点就是golang语言中的内存对齐概念（alignment guarantee），https://gfw.go101.org/article/memory-layout.html

类型的尺寸和结构体字节填充（structure padding）

Go白皮书只对以下种类的类型的尺寸进行了明确规定。

类型种类                  尺寸（字节数）
------                   ------
byte, uint8, int8        1
uint16, int16            2
uint32, int32, float32   4
uint64, int64            8
float64, complex64       8
complex128               16
uint, int                取决于编译器实现。通常在
                         32位架构上为4，在64位
                         架构上为8。
uintptr                  取决于编译器实现。但必须
                         能够存下任一个内存地址。

Go白皮书没有对其它种类的类型的尺寸最初明确规定。 请阅读值复制成本一文来获取标准编译器使用的各种其它类型的尺寸。

标准编译器（和gccgo编译器）将确保一个类型的尺寸为此类型的对齐保证的倍数。

为了满足上一节中规定的地址对齐保证要求，Go编译器可能会在结构体的相邻字段之间填充一些字节。 这使得一个结构体类型的尺寸并非等于它的各个字段类型尺寸的简单相加之和。

下面是一个展示了一些字节是如何填充到一个结构体中的例子。 首先，从上面的描述中，我们已得知（对于标准编译器来说）：

• 内置类型int8的对齐保证和尺寸均为1个字节； 内置类型int16的对齐保证和尺寸均为2个字节； 内置类型int64的尺寸为8个字节，但它的对齐保证在32位架构上为4个字节，在64位架构上为8个字节。
• 下例中的类型T1和T2的对齐保证均为它们的各个字段的最大对齐保证。 所以它们的对齐保证和内置类型int64相同，即在32位架构上为4个字节，在64位架构上为8个字节。
• 类型T1和T2尺寸需为它们的对齐保证的倍数，即在32位架构上为4n个字节，在64位架构上为8n个字节。

type T1 struct {
	a int8

	// 在64位架构上，为了让下一个字段b的地址为8字节对齐，
	// 需在在字段a这里填充7个字节。在32位架构上，为了让
	// 字段b的地址为4字节对齐，需在这里填充3个字节。

	b int64
	c int16

	// 为了让类型T1的尺寸为T1的对齐保证的倍数，
	// 在64位架构上需在这里填充6个字节，在32架构
	// 上需在这里填充2个字节。
}
// 类型T1的尺寸在64位架构上位24个字节（1+7+8+2+6），
// 在32位架构上为16个字节（1+3+8+2+2）。
// 以保存每个字段都是8（64位架构）或者4(32位架构)的的整数倍

type T2 struct {
	a int8

	// 为了让下一个字段c的地址为2字节对齐，
	// 需在字段a这里填充1个字节。

	c int16

	// 在64位架构上，为了让下一个字段b的地址为8字节对齐，
	// 需在字段c这里填充4个字节。在32位架构上，不需填充
	// 字节即可保证字段b的地址为4字节对齐的。

	b int64
}
// 类型T2的尺寸在64位架构上位16个字节（1+1+2+4+8），
// 在32位架构上为12个字节（1+1+2+8）。

从这个例子可以看出，尽管类型T1和T2拥有相同的字段集，但是它们的尺寸并不相等。每个字段的大小都要受下一个字段大小的影响，以方便下个字段对齐。所以建议在开发中，字段占用空间小的放在前面。

一个有趣的事实是有时候一个结构体类型中零尺寸类型的字段可能会影响到此结构体类型的尺寸。 请阅读此问答获取详情。

如果还有些模糊的话可以看一下这篇文章：https://blog.csdn.net/Lazyboy_/article/details/88579966

从调度上看，goroutine的调度开销远远小于线程调度开销。

OS的线程由OS内核调度，每隔几毫秒，一个硬件时钟中断发到CPU，CPU调用一个调度器内核函数。这个函数暂停当前正在运行的线程，把他的寄存器信息保存到内存中(暂时保存线程状态），查看线程列表并决定接下来运行哪一个线程，再从内存中恢复线程的注册表信息，最后继续执行选中的线程。这种线程切换需要一个完整的上下文切换：即保存一个线程的状态到内存，再恢复另外一个线程的状态，最后更新调度器的数据结构。某种意义上，这种操作还是很慢的。

Go运行的时候包涵一个自己的调度器，这个调度器使用一个称为一个M:N调度技术，m个goroutine到n个os线程（可以用GOMAXPROCS来控制n的数量），Go的调度器不是由硬件时钟来定期触发的，而是由特定的go语言结构来触发的，他不需要切换到内核语境，所以调度一个goroutine比调度一个线程的成本低很多。

从栈空间上，goroutine的栈空间更加动态灵活。

每个OS的线程都有一个固定大小的栈内存，通常是2MB，栈内存用于保存在其他函数调用期间哪些正在执行或者临时暂停的函数的局部变量。这个固定的栈大小，如果对于goroutine来说，可能是一种巨大的浪费。作为对比，goroutine在生命周期开始只有一个很小的栈，典型情况是2KB, 在go程序中，一次创建十万左右的goroutine也不罕见（2KB*100,000=200MB）。而且goroutine的栈不是固定大小，它可以按需增大和缩小，最大限制可以到1GB。

参考：https://time.geekbang.org/course/detail/160-86799

goroutine没有一个特定的标识。

在大部分支持多线程的操作系统和编程语言中，线程有一个独特的标识，通常是一个整数或者指针，这个特性可以让我们构建一个线程的局部存储，本质是一个全局的map，以线程的标识作为键，这样每个线程可以独立使用这个map存储和获取值，不受其他线程干扰。

goroutine中没有可供程序员访问的标识，原因是一种纯函数的理念，不希望滥用线程局部存储导致一个不健康的超距作用，即函数的行为不仅取决于它的参数，还取决于运行它的线程标识。

reference: 《Go程序设计语言》E-mail: huahuiyang@gmail.com https://www.linkedin.com/in/huahuiyang/

转自：https://www.cnblogs.com/yanghuahui/p/9043631.html

平时我们在写struct的时候，经常会用到一些方法，有些方法是我们熟悉的普通方法，在golang中我们称之为值方法，而另一种则是指针方法。

type Person struct {
    Firstname string
    Lastname string
    Age uint8
}
// 值方法
func (p Person) show() {
    fmt.Println(p.Firstname)
}

// 指针方法
func (p *Person) show2() {
    fmt.Println(p.Firstname)
}

可以看到所谓的值方法与指针方法在编写的时候，只是有无*号的区别，这个*就是指针的意思。

那么用法又有何不同呢？

// 值方法
func (p Person) setFirstName(name string) {
	p.Firstname = name
}
// 指针方法
func (p *Person) setFirstName2(name string) {
	p.Firstname = name
}

func main() {
	p := Person{"sun", "xingfang", 30}

	//不一致的情况
	p.show() // sun 修改前
	p.setFirstName("tom")	// 值方法
	p.show() // sun, 未变化

	p.show() // sun 修改前
	p.setFirstName2("tom")	// 指针方法
	p.show() // tom 修改后的tom
}

通过上面的输出我们可以看到，当调用值方法setFirstName后，输出的还是原来的值sun，而调用指针方法 setFirstNam2后，则输出的是新值。主要原因就是值方法在传递总结体的时候，用的只是原来结构体的一个副本，做的任何修改也只是对副本的修改，而打印的还是原来的结构体，两者互不影响。而指针方法，传递的则是指向结构体指针的值副本，指针值一样(X012242R424)，指定的都是底层的数据结构，所以才会出现这种情况。

总结：

1. 值方法的接收者是该方法所属的那个类型值的一个副本。我们在该方法内对该副本的修1改一般都不会体现在原值上，除非这个类型本身是某个引用类型（比如切片或字典）的别名类型。 而指针方法的接收者，是该方法所属的那个基本类型值的指针值的一个副本。我们在这样的方法内对该副本指向的值进行修改，却一定会体现在原值上。
2. 一个自定义数据类型的方法集合中仅会包含它的所有值方法，而该类型的指针类型的方法集合却囊括了前者的所有方法，包括所有值方法和所有指针方法。
   严格来讲，我们在这样的基本类型的值上只能调用到它的值方法。但是，Go 语言会适时地为我们进行自动地转译，使得我们在这样的值上也能调用到它的指针方法。本示例中的 p.show() 在调用的时候会自动转换成 show2() 这种指针方式，可以试着将例子中的 show() 改成 show2() 输出结果是一样的)比如，在Cat类型的变量cat之上，之所以我们可以通过cat.SetName(“monster”)修改猫的名字，是因为 Go 语言把它自动转译为了(&cat).SetName(“monster”)，即：先取cat的指针值，然后在该指针值上调用SetName方法。以上是由“郝林”老师在“Go语言核心36讲”专栏中总结。
3. 两种写法在使用接口的时候也会有所不同。

测试环境:
系统 win7 64位
go version: go1.10 windows/amd64

我们先看一下代码的输出

package main

import "unsafe"

func main() {
	// string
	str1 := "abc"
	println("string1:", unsafe.Sizeof(str1)) // 16
	str2 := "abcdef"
	println("string2:", unsafe.Sizeof(str2)) // 16
	
	// 数组
	arr1 := [...]int{1, 2, 3, 4}
	println("array1:", unsafe.Sizeof(arr1)) // 32 = 8 * 4

	arr2 := [...]int{1, 2, 3, 4, 5}
	println("array2:", unsafe.Sizeof(arr2)) // 40 = 8 * 5

	// slice 好多人分不清切片和数组的写法区别，其实只要记住[]中间是空的就是切片，反之则是数组即可
	slice1 := []int{1, 2, 3, 4}
	println("slice1:", unsafe.Sizeof(slice1)) // 24

	slice2 := []int{1, 2, 3, 4, 5}
	println("slice2:", unsafe.Sizeof(slice2)) // 24

	slice3 := []int{1, 2, 3, 4, 5, 6, 7, 8, 9, 10}
	println("slice3:", unsafe.Sizeof(slice3)) // 24
}

typedef struct {
    char* buffer;
    size_tlen;
} string;

不同数据类型占用字节大小如下：

func main() {
	var a uint8
	a = 2
	fmt.Println("uint8 type size:", unsafe.Sizeof(a))

	var b uint16
	b = 2
	fmt.Println("uint16 type size:", unsafe.Sizeof(b))

	
	var c uint32
	c = 2
	fmt.Println("uint32 type size:", unsafe.Sizeof(c))
	
	var d uint64
	d = 2
	fmt.Println("uint64 type size:", unsafe.Sizeof(d))
}

数据类型