pom关键字

dependencies:项目的依赖配置

dependencyManagement:项目的依赖管理配置

build: 包括项目的源码目录配置,输出目录配置,插件配置,插件管理配置等。

依赖管理:见《Maven实战》 8.3.3

Go语言垃圾回收机制

如何知道一个变量是何时可以被回收的呢?

基本思路:从每个包级的变量和每个当前运行函数的每一个局部变量开始,通过指针或引用的访问路径遍历,是否可以找到还变量。如果不存在这样的访问路径,那么说明该变量是不可达的,也就是说它是否存在并不影响程序后续的计算结果。

因此一个循环迭代内部的局部变量的生命周期可能超出其局部作用域。同时,局部变量可能在函数返回之后依然存在。

 

编译器会自动选择在栈上还是在堆上分配局部变量的存储空间,但可能令人惊讶的是,这个选择并不是由用var还是new声明变量的方式决定的。

 

var global *int

 

func f() {

var x int

x = 1

global = &x

}

 

func g() {

y := new(int)

*y = 1

}

f函数里的x变量必须在堆上分配,因为它在函数退出后依然可以通过包一级的global变量找到,虽然它是在函数内部定义的;用Go语言的术语说,这个x局部变量从函数f中逃逸了。相反,当g函数返回时,变量*y将是不可达的,也就是说可以马上被回收的。因此,*y并没有从函数g中逃逸,编译器可以选择在栈上分配*y的存储空间(译注:也可以选择在堆上分配,然后由Go语言的GC回收这个变量的内存空间),虽然这里用的是new方式。其实在任何时候,你并不需为了编写正确的代码而要考虑变量的逃逸行为,要记住的是,逃逸的变量需要额外分配内存,同时对性能的优化可能会产生细微的影响。

 

Go语言的自动垃圾收集器对编写正确的代码是一个巨大的帮助,但也并不是说你完全不用考虑内存了。你虽然不需要显式地分配和释放内存,但是要编写高效的程序你依然需要了解变量的生命周期。例如,如果将指向短生命周期对象的指针保存到具有长生命周期的对象中,特别是保存到全局变量时,会阻止对短生命周期对象的垃圾回收(从而可能影响程序的性能)。

 

大流量,低时延

未来的社会是个智能社会,大流量、低时延的管道是未来智能社会的基础,也是华为的大机会。

没有正确的假设,就没有正确的方向;没有正确的方向,就没有正确的思想;没有正确的思想,就没有正确的理论;没有正确的理论,就不可能出来正确的战略。