一期Go群问答-并发控制-数据竞争-错误与异常

每周更新Go技术交流群的群问答内容，有需要可发我Go加群讨论学习。

并发控制

waitGroup.done()不是必须写在main方法中吗? 为什么我的协程没有成功等待？

熊：如果用了wait group，请求就直接卡住了，如果只有一个goroutine那和直接调用函数没有区别其实。你是想请求立刻返回，然后其他数据稍后返回的话，用中间件比如kafka。或者用回调callback

错误现场

错误原因：没有能成功等待goroutine执行完，done要放goroutine里，外面是wait。

参考用例

var wg sync.WaitGroup
sList := []string{"a", "b"}
wg.Add(len(sList))
for _, d := range sList {go func() {defer wg.Done()fmt.Println(d)}()}
wg.Wait()

数据竞争

如果不同的线程写同一个map的不同key内容是不是不用sync.Map了？会存在数据竞争吗？但是如果我make的时候提前指定容量呢？

熊：会影响的，估计map中的hmap会影响到，有几率会在运行时报错

机器马：你在用之前没法确定会用哪个key啊，除非你再用结构体封装一层

熊：我想到两个办法，1是用这个，还有一个是弄个channel，如果数据用途不一样，弄成结构体channel，用一个goroutine来接收他们。单独用一个线程来接受数据，go这个东西就是个语言，怎么好用怎么来，虽然一直是在推channel，但只要实现需求。

sync.Map为什么没有len测长度方法？

Mike：看来有人也遇到这么问题，为杀map支持len()，而sync.Map不支持。有兴趣的可以看看issue. 简单说官方认为 map 本来就不应该有length的实现。

机器马： 2017年社区就在吵要不要加个len方法了。一般syncmap都不会单独使用,而是封装到结构体里，然后再写一层方法，所以一般就会在这一层做count，用原子操作计数。

追问：sync.Map 这个Range 方法有个返回值，是bool是用来返回是否range空map吗？range如何处理碰到到空的？

熊：这个bool是传入函数的返回值，调用完以后如果是Map是空的，实际上就什么也没做，不会给返回。里面给迭代，你传入的函数处理下k v的行了。没办法判断是否为空。

登陆验证

我们可以用UUID生成我们的token，为什么还要用jwt呢（redis中存储token和用户信息对应关系）？

Mike：无状态 jwt不在服务端存储任何状态。RESTful API的原则之一是无状态，通过redis存储token和用户信息，违背了无状态原则。

Mike： JWT的优点：

可扩展性好应用程序分布式部署的情况下，session 需要做多机数据共享，通常可以存在数据库或者redis里面。而jwt不需要。
无状态 jwt不在服务端存储任何状态。RESTful API的原则之一是无状态，发出请求时，总会返回带有参数的响应，不会产生附加影响。用户的认证状态引入这种附加影响，这破坏了这一原则。另外jwt的载荷中可以存储一些常用信息，用于交换信息，有效地使用 JWT，可以降低服务器查询数据库的次数。

Mike：缺点：由于jwt的payload是使用base64编码的，并没有加密，因此jwt中不能存储敏感数据。而session的信息是存在服务端的，相对来说更安全。

熊：关于前端现实当前是哪个用户的问题，只需要后端把用户基本信息存cookie里就可以了。后端用token获取用户信息，把二者分离开。

熊：关于Mike所述的第一个优点，实际上也有弊端，因为必须等待token记录的时间到期，jwt才会判定token过期，服务端无法主动过期。也无法做多平台挤出登陆，类似于QQ那样子。
熊：gtoken就是存redis

此用户名已被占用: jwt一般还要再加密吧?我记得是有rsa
熊：确实是要加密的

宋跑跑：签名加密？

此用户名已被占用: 难道不是吗? 不然token裸奔。

宋跑跑 (宋跑跑): 害信息其实都能拿到了。

异常处理

go你们在项目中都是怎么异常处理的呀，java是抛出自定义有业务异常然后全局异常捕获？

张朝胤：Golang不是if err=nil？全局try catch怎么处理？

Mike： fmt. Errorf 可以包装多层错误，再用 errors.ls集中判断。没必要把java里面那一套带进Go，这两门语言的哲学本来就不一样。

宋跑跑：recover

国玮： exception != error,错误是错误异常是异常,错误是可以考虑降级处理不影响程序运行的异常反之。例如最常用的 error 级别，Go 语言贡献者 Davio 认为，对错误进行降级处理后，应该打印 info 级别的日志，这意味着我处理了错误，或者往上抛并 warp 它。不过我不是很赞同这个观点 info 和 error 的处理是完全不同的。错误就该打出来。

国玮：对于错误其实Go的哲学就是 error is value，你把它当做一个值来处理，exception 是那种会让程序崩溃的，崩溃恢复用recover就行。

吆吆好叼啊：可以这么理解吗？service层出现异常直接返回，controller层调用service层方法进行处理，如果出现错误，controller层返回前端自定义异常json数。

国玮：可以，调用者处理错误。不需要像java那样抛出业务异常，有个专门的对controller层处理的异常处理类。但是这句话里面，要注意，是错误，不是异常！要弄清楚它们的概念呀。

国玮： Java 中的异常，是可以继承的，那么就是说父 exception 可以接收一切子 exception，这就没有做到细分。

国玮：错误可以用 Wrap 一层一层往上抛（error std lib 的一个方法），大概意思就是 Warp 去包装错误，为错误提供更多的“证据”和“线索”，但是并没有真正的处理错误，处理错误本质上还是交给调用者。

Mike：其实很灵活的，对于错误处理完全看业务需要，有些错误可以跳过，有些不行，必须得返回。

国玮：嗯嗯，在实际编码中，确实是这样的，不过 Dave 认为，如果你对错误不关心，那么你也不应该关心它返回的值。可能是提醒我们要谨慎吧！

其他

大家有go 单体项目推荐吗，我阅读阅读（最好是格式规范）？

https://github.com/golang-standards/project-layout

本文由mdnice多平台发布