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

[darasion]

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

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

这样的问题咋解决？

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

比如这样就会产生竞争：

https://gist.github.com/darasion/30ea7cb5a90750ef9627  显示 Gist 代码 

[mengzhuo]

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

[bcxx]

多用 interface ...

[elgoog1970]

go is not java

[zonghua]

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

[zyguan]

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

[darasion]

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

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

[zyguan]

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

[mengzhuo]

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