go语言怎么节省内存消耗 go语言内存占用

Golang 1.14中内存分配、清扫和内存回收 Golang的内存分配是由golang runtime完成,其内存分配方案借鉴自tcmalloc 。
主要特点就是
本文中的element指一定大小的内存块是内存分配的概念,并为出现在golang runtime源码中
本文讲述x8664架构下的内存分配
Golang 内存分配有下面几个主要结构
Tiny对象是指内存尺寸小于16B的对象 , 这类对象的分配使用mcache的tiny区域进行分配 。当tiny区域空间耗尽时刻 , 它会从mcache.alloc[tinySpanClass]指向的mspan中找到空闲的区域 。当然如果mcache中span空间也耗尽,它会触发从mcentral补充mspan到mcache的流程 。
小对象是指对象尺寸在(16B,32KB]之间的对象,这类对象的分配原则是:
1、首先根据对象尺寸将对象归为某个SpanClass上,这个SpanClass上所有的element都是一个统一的尺寸 。
2、从mcache.alloc[SpanClass]找到mspan,看看有无空闲的element,如果有分配成功 。如果没有继续 。
3、从mcentral.allocSpan[SpanClass]的nonempty和emtpy中找到合适的mspan,返回给mcache 。如果没有找到就进入mcentral.grow()—mheap.alloc()分配新的mspan给mcentral 。
大对象指尺寸超出32KB的对象 , 此时直接从mheap中分配 , 不会走mcache和mcentral,直接走mheap.alloc()分配一个SpanClass==0 的mspan表示这部分分配空间 。
对于程序分配常用的tiny和小对象的分配,可以通过无锁的mcache提升分配性能 。mcache不足时刻会拿mcentral的锁,然后从mcentral中充mspan 给mcache 。大对象直接从mheap 中分配 。
在x8664环境上,golang管理的有效的程序虚拟地址空间实质上只有48位 。在mheap中有一个pages pageAlloc成员用于管理golang堆内存的地址空间 。golang从os中申请地址空间给自己管理,地址空间申请下来以后,golang会将地址空间根据实际使用情况标记为free或者alloc 。如果地址空间被分配给mspan或大对象后,那么被标记为alloc,反之就是free 。
Golang认为地址空间有以下4种状态:
Golang同时定义了下面几个地址空间操作函数:
在mheap结构中,有一个名为pages成员 , 它用于golang 堆使用虚拟地址空间进行管理 。其类型为pageAlloc
pageAlloc 结构表示的golang 堆的所有地址空间 。其中最重要的成员有两个:
【go语言怎么节省内存消耗 go语言内存占用】 在golang的gc流程中会将未使用的对象标记为未使用,但是这些对象所使用的地址空间并未交还给os 。地址空间的申请和释放都是以golang的page为单位(实际以chunk为单位)进行的 。sweep的最终结果只是将某个地址空间标记可被分配,并未真正释放地址空间给os,真正释放是后文的scavenge过程 。
在gc mark结束以后会使用sweep()去尝试free一个span;在mheap.alloc 申请mspan时刻,也使用sweep去清扫一下 。
清扫mspan主要涉及到下面函数
如上节所述,sweep只是将page标记为可分配,但是并未把地址空间释放;真正的地址空间释放是scavenge过程 。
真正的scavenge是由pageAlloc.scavenge()—sysUnused()将扫描到待释放的chunk所表示的地址空间释放掉(使用sysUnused()将地址空间还给os)
golang的scavenge过程有两种:
为什么要使用 Go 语言,Go 语言的优势在哪里部署简单 。Go编译生成的是一个静态可执行文件,除了glibc外没有其他外部依赖 。这让部署变得异常方便:目标机器上只需要一个基础的系统和必要的管理、监控工具,完全不需要操心应用所需的各种包、库的依赖关系,大大减轻了维护的负担 。这和Python有着巨大的区别 。由于历史的原因,Python的部署工具生态相当混乱【比如setuptools,distutils,pip,
buildout的不同适用场合以及兼容性问题】 。官方PyPI源又经常出问题,需要搭建私有镜像,而维护这个镜像又要花费不少时间和精力 。
并发性好 。Goroutine和channel使得编写高并发的服务端软件变得相当容易,很多情况下完全不需要考虑锁机制以及由此带来的各种问题 。单个Go应用也能有效的利用多个CPU核 , 并行执行的性能好 。这和Python也是天壤之比 。多线程和多进程的服务端程序编写起来并不简单,而且由于全局锁GIL的原因,多线程的Python程序并不能有效利用多核,只能用多进程的方式部署;如果用标准库里的multiprocessing包又会对监控和管理造成不少的挑战【我们用的supervisor管理进程,对fork支持不好】 。部署Python应用的时候通常是每个CPU核部署一个应用,这会造成不少资源的浪费,比如假设某个Python应用启动后需要占用100MB内存,而服务器有32个CPU核,那么留一个核给系统、运行31个应用副本就要浪费3GB的内存资源 。
良好的语言设计 。从学术的角度讲Go语言其实非常平庸 , 不支持许多高级的语言特性;但从工程的角度讲,Go的设计是非常优秀的:规范足够简单灵活,有其他语言基础的程序员都能迅速上手 。更重要的是Go自带完善的工具链,大大提高了团队协作的一致性 。比如gofmt自动排版Go代码,很大程度上杜绝了不同人写的代码排版风格不一致的问题 。把编辑器配置成在编辑存档的时候自动运行gofmt , 这样在编写代码的时候可以随意摆放位置,存档的时候自动变成正确排版的代码 。此外还有gofix,
govet等非常有用的工具 。
执行性能好 。虽然不如C和Java,但通常比原生Python应用还是高一个数量级的,适合编写一些瓶颈业务 。内存占用也非常省 。
8年java转go很痛苦困难肯定是有的 。但你如果确定要转go语言怎么节省内存消耗了go语言怎么节省内存消耗,就要对得起自己的决定 。虽然困难,也要勇往直前 。
知乎用户枫泪也有和你类似的经历 。他认为golang无论是从语法还是到性能,真的是比java好太多了 , java现在就是生态比较好,但是云服务这块go有天然优势,无论是阿里,华为,腾讯,百度这些大厂 , 都不断加强go语言的使用比重 。go语言相对于java内存消耗少的多,也就是对于服务器方面,使用go语言可以赤裸裸的省钱 。
Go 语言内存管理(三):逃逸分析Go 语言较之 C 语言一个很大的优势就是自带 GC 功能 , 可 GC 并不是没有代价的 。写 C 语言的时候,在一个函数内声明的变量,在函数退出后会自动释放掉 , 因为这些变量分配在栈上 。如果你期望变量的数据可以在函数退出后仍然能被访问,就需要调用malloc方法在堆上申请内存,如果程序不再需要这块内存了,再调用free方法释放掉 。Go 语言不需要你主动调用malloc来分配堆空间,编译器会自动分析,找出需要malloc的变量 , 使用堆内存 。编译器的这个分析过程就叫做逃逸分析 。
所以你在一个函数中通过dict := make(map[string]int)创建一个 map 变量,其背后的数据是放在栈空间上还是堆空间上,是不一定的 。这要看编译器分析的结果 。
可逃逸分析并不是百分百准确的 , 它有缺陷 。有的时候你会发现有些变量其实在栈空间上分配完全没问题的,但编译后程序还是把这些数据放在了堆上 。如果你了解 Go 语言编译器逃逸分析的机制,在写代码的时候就可以有意识地绕开这些缺陷,使你的程序更高效 。
Go 语言虽然在内存管理方面降低了编程门槛,即使你不了解堆栈也能正常开发 , 但如果你要在性能上较真的话,还是要掌握这些基础知识 。
这里不对堆内存和栈内存的区别做太多阐述 。简单来说就是 , 栈分配廉价,堆分配昂贵 。栈空间会随着一个函数的结束自动释放,堆空间需要时间 GC 模块不断地跟踪扫描回收 。如果对这两个概念有些迷糊,建议阅读下面 2 个文章:
这里举一个小例子,来对比下堆栈的差别:
stack函数中的变量i在函数退出会自动释放;而heap函数返回的是对变量i的引用 , 也就是说heap()退出后,表示变量i还要能被访问,它会自动被分配到堆空间上 。
他们编译出来的代码如下:
逻辑的复杂度不言而喻,从上面的汇编中可看到,heap()函数调用了runtime.newobject()方法,它会调用mallocgc方法从mcache上申请内存 , 申请的内部逻辑前面文章已经讲述过 。堆内存分配不仅分配上逻辑比栈空间分配复杂,它最致命的是会带来很大的管理成本 , Go 语言要消耗很多的计算资源对其进行标记回收(也就是 GC 成本) 。
Go 编辑器会自动帮我们找出需要进行动态分配的变量,它是在编译时追踪一个变量的生命周期 , 如果能确认一个数据只在函数空间内访问,不会被外部使用,则使用栈空间,否则就要使用堆空间 。
我们在go build编译代码时,可使用-gcflags '-m'参数来查看逃逸分析日志 。
以上面的两个函数为例,编译的日志输出是:
日志中的i escapes to heap表示该变量数据逃逸到了堆上 。
需要使用堆空间,所以逃逸,这没什么可争议的 。但编译器有时会将不需要使用堆空间的变量,也逃逸掉 。这里是容易出现性能问题的大坑 。网上有很多相关文章,列举了一些导致逃逸情况,其实总结起来就一句话:
多级间接赋值容易导致逃逸。
这里的多级间接指的是,对某个引用类对象中的引用类成员进行赋值 。Go 语言中的引用类数据类型有func,interface,slice,map,chan,*Type(指针)。
记住公式Data.Field = Value , 如果Data,Field都是引用类的数据类型,则会导致Value逃逸 。这里的等号=不单单只赋值,也表示参数传递 。
根据公式,我们假设一个变量data是以下几种类型,相应的可以得出结论:
下面给出一些实际的例子:
如果变量值是一个函数,函数的参数又是引用类型,则传递给它的参数都会逃逸 。
上例中te的类型是func(*int),属于引用类型,参数*int也是引用类型,则调用te(j)形成了为te的参数(成员)*int赋值的现象 , 即te.i = j会导致逃逸 。代码中其他几种调用都没有形成 多级间接赋值 情况 。
同理,如果函数的参数类型是slice,map或interface{}都会导致参数逃逸 。
匿名函数的调用也是一样的 , 它本质上也是一个函数变量 。有兴趣的可以自己测试一下 。
只要使用了Interface类型(不是interafce{}),那么赋值给它的变量一定会逃逸 。因为interfaceVariable.Method()先是间接的定位到它的实际值,再调用实际值的同名方法,执行时实际值作为参数传递给方法 。相当于interfaceVariable.Method.this = realValue
向 channel 中发送数据,本质上就是为 channel 内部的成员赋值,就像给一个 slice 中的某一项赋值一样 。所以chan *Type,chan map[Type]Type,chan []Type,chan interface{}类型都会导致发送到 channel 中的数据逃逸 。
这本来也是情理之中的,发送给 channel 的数据是要与其他函数分享的,为了保证发送过去的指针依然可用,只能使用堆分配 。
可变参数如func(arg ...string)实际与func(arg []string)是一样的,会增加一层访问路径 。这也是fmt.Sprintf总是会使参数逃逸的原因 。
例子非常多,这里不能一一列举 , 我们只需要记住分析方法就好,即,2 级或更多级的访问赋值会容易导致数据逃逸 。这里加上容易二字是因为随着语言的发展,相信这些问题会被慢慢解决,但现阶段,这个可以作为我们分析逃逸现象的依据 。
下面代码中包含 2 种很常规的写法,但他们却有着很大的性能差距 , 建议自己想下为什么 。
Benchmark 和 pprof 给出的结果:
熟悉堆栈概念可以让我们更容易看透 Go 程序的性能问题,并进行优化 。
多级间接赋值会导致 Go 编译器出现不必要的逃逸 , 在一些情况下可能我们只需要修改一下数据结构就会使性能有大幅提升 。这也是很多人不推荐在 Go 中使用指针的原因,因为它会增加一级访问路径,而map,slice,interface{}等类型是不可避免要用到的 , 为了减少不必要的逃逸,只能拿指针开刀了 。
大多数情况下 , 性能优化都会为程序带来一定的复杂度 。建议实际项目中还是怎么方便怎么写,功能完成后通过性能分析找到瓶颈所在,再对局部进行优化 。
关于go语言怎么节省内存消耗和go语言内存占用的介绍到此就结束了,不知道你从中找到你需要的信息了吗 ?如果你还想了解更多这方面的信息 , 记得收藏关注本站 。

    推荐阅读