Go语言os标准库常用方法GetwdGetenvChdir

Python08

Go语言os标准库常用方法GetwdGetenvChdir,第1张

1. os.Getwd()函数

原型:func Getwd()(pwd string, err error)

作用:获取当前文件路径

返回:当前文件路径的字符串和一个err信息

示例:

输出:

当前路径: D:ProjectsGomGoLab01

2. os.Getenv()函数

原型:func Getenv(key string) string

作用:获取系统环境变量的值

参数:key - 系统环境变量名

返回:系统环境变量的值

示例:

输出:

环境变量GOPATH的值是: D:/Projects/Go

3. os.Chdir()函数

原型:func Chdir(dir string) error

作用:将当前文件路径改变为目标路径(非真实改变)

参数:dir - 目标路径(即改变之后的路径)

返回:修改成功,返回 nil;修改失败(如:目标路径不存在的情况),返回错误信息。

示例一:

输出:

起始路径: D:ProjectsGomGoLab01

修改后的路径: D:ProjectsGoDemo02

示例二:

输出:

起始路径: D:ProjectsGomGoLab01

error: chdir D:ProjectsGoDemo03: The system cannot find the file specified.

注:文件路径,Window 系统下默认是“”,写在代码中时要用“”或“/”代替。

    运行panic异常一旦被引发就会导致程序崩溃,这当然不是我们愿意看到的,go语言提供乐专用于“拦截”运行时panic的内建函数-recover,它可以是当前的程序从运行时panic的状态中恢复并重新获得流程控制权。

    注意:recover只有在defer调用的函数中有效

    如果调用了内置函数recover,并且定义该defer语句的函数发生了panic异常,recover会使用程序从panic中恢复,并且返回panic value,导致panic异常的函数不会继续执行,但能正常返回。在未发生panic时调用recover,recover会返回nil。

在go http每一次go serve(l)都会构建Request数据结构。在大量数据请求或高并发的场景中,频繁创建销毁对象,会导致GC压力。解决办法之一就是使用对象复用技术。在http协议层之下,使用对象复用技术创建Request数据结构。在http协议层之上,可以使用对象复用技术创建(w,*r,ctx)数据结构。这样即可以回快TCP层读包之后的解析速度,也可也加快请求处理的速度。

先上一个测试:

结论是这样的:

貌似使用池化,性能弱爆了???这似乎与net/http使用sync.pool池化Request来优化性能的选择相违背。这同时也说明了一个问题,好的东西,如果滥用反而造成了性能成倍的下降。在看过pool原理之后,结合实例,将给出正确的使用方法,并给出预期的效果。

sync.Pool是一个 协程安全 临时对象池 。数据结构如下:

local 成员的真实类型是一个 poolLocal 数组,localSize 是数组长度。这涉及到Pool实现,pool为每个P分配了一个对象,P数量设置为runtime.GOMAXPROCS(0)。在并发读写时,goroutine绑定的P有对象,先用自己的,没有去偷其它P的。go语言将数据分散在了各个真正运行的P中,降低了锁竞争,提高了并发能力。

不要习惯性地误认为New是一个关键字,这里的New是Pool的一个字段,也是一个闭包名称。其API:

如果不指定New字段,对象池为空时会返回nil,而不是一个新构建的对象。Get()到的对象是随机的。

原生sync.Pool的问题是,Pool中的对象会被GC清理掉,这使得sync.Pool只适合做简单地对象池,不适合作连接池。

pool创建时不能指定大小,没有数量限制。pool中对象会被GC清掉,只存在于两次GC之间。实现是pool的init方法注册了一个poolCleanup()函数,这个方法在GC之前执行,清空pool中的所有缓存对象。

为使多协程使用同一个POOL。最基本的想法就是每个协程,加锁去操作共享的POOL,这显然是低效的。而进一步改进,类似于ConcurrentHashMap(JDK7)的分Segment,提高其并发性可以一定程度性缓解。

注意到pool中的对象是无差异性的,加锁或者分段加锁都不是较好的做法。go的做法是为每一个绑定协程的P都分配一个子池。每个子池又分为私有池和共享列表。共享列表是分别存放在各个P之上的共享区域,而不是各个P共享的一块内存。协程拿自己P里的子池对象不需要加锁,拿共享列表中的就需要加锁了。

Get对象过程:

Put过程:

如何解决Get最坏情况遍历所有P才获取得对象呢:

方法1止前sync.pool并没有这样的设置。方法2由于goroutine被分配到哪个P由调度器调度不可控,无法确保其平衡。

由于不可控的GC导致生命周期过短,且池大小不可控,因而不适合作连接池。仅适用于增加对象重用机率,减少GC负担。2

执行结果:

单线程情况下,遍历其它无元素的P,长时间加锁性能低下。启用协程改善。

结果:

测试场景在goroutines远大于GOMAXPROCS情况下,与非池化性能差异巨大。

测试结果

可以看到同样使用*sync.pool,较大池大小的命中率较高,性能远高于空池。

结论:pool在一定的使用条件下提高并发性能,条件1是协程数远大于GOMAXPROCS,条件2是池中对象远大于GOMAXPROCS。归结成一个原因就是使对象在各个P中均匀分布。

池pool和缓存cache的区别。池的意思是,池内对象是可以互换的,不关心具体值,甚至不需要区分是新建的还是从池中拿出的。缓存指的是KV映射,缓存里的值互不相同,清除机制更为复杂。缓存清除算法如LRU、LIRS缓存算法。

池空间回收的几种方式。一些是GC前回收,一些是基于时钟或弱引用回收。最终确定在GC时回收Pool内对象,即不回避GC。用java的GC解释弱引用。GC的四种引用:强引用、弱引用、软引用、虚引用。虚引用即没有引用,弱引用GC但有空间则保留,软引用GC即清除。ThreadLocal的值为弱引用的例子。

regexp 包为了保证并发时使用同一个正则,而维护了一组状态机。

fmt包做字串拼接,从sync.pool拿[]byte对象。避免频繁构建再GC效率高很多。