Go 是否需要使用 getter / setter ？如果需要，什么情况应该使用？

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

The Go Programming Language

› http://golang.org/

› Go Playground

Go Projects

› Revel Web Framework

这是一个创建于 3586 天前的主题，其中的信息可能已经有所发展或是发生改变。

我看大部分情况下是不需要的，但是有时候要给读写的时候加个锁，这时候就貌似必须得有这个了。

如果一个 struct 有了 getter / setter 而其他的没有，就显得很不统一，最后的代码很难看的样子，有时候还记不住哪个有哪个没有了。

这样的问题咋解决？

第 1 条附言 · 2016 年 3 月 23 日

看来是不需要的。
http.Server 就没有任何锁，不作任何限制，全靠自觉。

比如这样就会产生竞争：

https://gist.github.com/darasion/30ea7cb5a90750ef9627

8 条回复 • 2016-03-23 12:09:04 +08:00

mengzhuo

2016 年 3 月 22 日 via iPhone

囧
碰到这样的的说明你的上层接口设计不当
所有需要锁的地方都要用统一的 get set

bcxx

2016 年 3 月 22 日

多用 interface ...

elgoog1970

2016 年 3 月 22 日

go is not java

zonghua

2016 年 3 月 22 日

@elgoog1970 让我又想到了递归命名法， go is not java `ginj`

zyguan

2016 年 3 月 22 日

如果你的实现不可避免的存在竞争条件，那加锁也没什么可耻的。而且加锁也不是非要在 getter/setter 上加，别套用 java 的 synchronized ，完全可以在相关逻辑代码中加，如果逻辑复杂多处竞争，那你就真该考虑优化优化设计了。另外，既然用 go ，那还是尽量多用 channel 少用共享可变量吧。

darasion

2016 年 3 月 23 日

@mengzhuo 因为不是所有地方都需要，不统一，所以才纠结。

@zyguan 如果我想在内存中保存一个列表，不断的有各路 goroutine 更新它的某些元素， channel 怎么做？

zyguan

2016 年 3 月 23 日

@darasion 另开一个 goroutine 专门维护这个列表，其它各路 goroutines 通过 channel 和它通信，这样就没必要加锁了。当然，前提是对这个列表的更新或访问不会频繁到成为瓶颈。实际上，如果成为瓶颈了，即使用锁来同步，也不会好哪去，这时应该考虑对这列表进行分区了。个人愚见，仅供参考。

mengzhuo

2016 年 3 月 23 日

@darasion 能用楼上的 Channel 就用，实在用不了再看数量，多的就统一，少的话，业务函数自己上锁。

Go 是否需要使用 getter / setter ？ 如果需要，什么情况应该使用？

Go 是否需要使用 getter / setter ？如果需要，什么情况应该使用？